It should be possible to customize the security scheme. An administrator should be able to define any roles they wish, with whatever permissions they like. This would allow security to be tailored to the needs of each organization.

The standard scheme is fairly complex - more complex than many organizations need, while not necessarily fitting their practices correctly.

Even better, it should be possible to define multiple security schemes as assign different schemes to different projects.


  • There is not any way I can restrict who can create templates. Our users often edit existing templates by mistake instead of using templates. Its too bad you have the “edit/create” template page be the same as the “use” template page. Customizable security would give me control over who can create or edit templates.

  • The current scheme is very rigid - I don't find it complex but it doesn't fit our requirements at all.

  • We just had a situation where a developer accidentally deleted an active user story. This created a lot of confusion. The tool should allow me to restrict WHO is able to delete and allow me to recover any items that were acidentally deleted.

  • Agree with the last comment in particular - we would like to be able to lock-out the delete function for most users. Only way around this at the moment is to set up a watch subscription to notify me if any stories, defects or other assets are deleted, which is a pain to monitor.

  • I agree - I would love to ability to customize the security model. In the default model you are more or less forced to assign "team member" role to both members and product owners. I wanted to restrict story editing access to product owners only and I could not.

  • A fully customizable security model would make VersionOne more readily acceptable to groups in regulated industries trying to implement agile. Often, regulations are particular about who can add, approve (close in V1 for the most part), delete etc. The current fixed model can never meet all the possible requirements of such regulations. Then, the use of VersionOne means the creation and documentation of more procedures to control the gaps left by the fixed model.

    Also, I agree with Wendy C. The inability to recover deleted items from the UI is a huge short-coming.

  • I would like a way to restrict who can move items in/out of releases and sprints to Project Leads.

  • the current security roles are very unhelpful in terms of the day to day admin of VersionOne. Maybe in a glossy brochure, the roles matrix looks good, but practically, it is of little value to me.

  • We are a new team using VersionOne. It would be easier to implement if we could put in place rules to control what users are able to do and under what conditions.

  • would be great if you could turn more things on and off instead of it being all or nothing.

    For example:
    Project Lead access - would be great if there was another level so we were able to limit who was able to get into the Administration section. Just b/c someone needs to be able to work with Sprint schedules does not mean they need to be able to create adn edit Team information at the Administration level.

  • As a system administrator, I should be able to make global changes without having to be added to every project as a Project Lead. The current solution (of being added to each project) is a very inefficient way to manage the tool at the organizational level.

  • The challenge with these blanket global prohibitions is that they also affect us, admins, when we're trying to support people/orgs. But today it's unavoidable since we cannot selectively choose who can and cannot do specific tasks. That's why, at some point, I really wish V1 would get updated with a more flexible role-based security model where we (admins) can define custom roles and turn specific things, like Excel imports or the bulk update API, for example, off for specific custom roles so we don't affect other things and other people in different roles. Please, please, please add this to your roadmap. I used to direct software development teams building enterprise software solutions for the energy and fintech markets. We always built in a flexible role-based model that could be defined by our customers' own admins. The fact you cannot, today, do this in V1 is a miss that should be addressed.