This article will share some tips and best practices for planning and creating the roles for your application.
Default Roles
All new applications come with 2 default roles, plus uses the Record Owner virtual role:
- Editor – This role is given record creator rights to all forms created in the application, along with Editor rights to to both of the default workflow stages in all new forms. (If it still exists in the application.)
- Readers – This role is given record creator rights to all forms created in the application, along with View rights to both of the default workflow stages in all new forms. (If it still exists in the application.)
- Record Owner (Virtual Role) – This role is given Editor rights to to both of the default workflow stages in all new forms. It gives the assigned permissions to the person who created the record. Therefore, it can, and often will, have a different person assigned for different records.
As you might have guessed from those descriptions, the idea of the Editors role is to be able to edit all records in the application, no matter which workflow stage they are at. The Readers role will be able to read all records at any workflow stage, but not edit them. And finally, whoever created a record will be able to edit the record, no matter which workflow stage it is at
You might find that many applications you create will indeed use these two default roles, but others might not. You will also be very likely to need additional roles in your applications. The notes below give you some ideas to help plan your roles.
- Managing Record Creation
- If your application needs most people to be able to create records and then access and even edit the records they created, then an Editor type role will be required. The Editor role is assigned to most users and is given record creator rights on the form (Settings tab). The workflow is then designed to give Record Owner the required View Only, Edit Only or Edit & Delete stage permissions, which is what allows the user to keep working with the records they created. Vacation Requests, Expense Reports or Bug Tracker are examples of the kinds of apps that are likely to need an Editor type role.
- If your application needs only a few specific people to be able to create and edit records, then an Editor type role will probably not be required. The users who should be able to create and edit records are assigned to a role like Editor and the record creator rights and workflow are set to allow that Editor role to create and edit records. Another Reader or Viewer role could be used to let others see but not edit records. Asset Management, Employee On-Boarding and Training Course Management are examples of the kinds of apps that are likely to need an Initiator type role.
- Managing Look-up Records
- If your application will have special forms to manage look-up values for the main forms, such as department names or product types, then it is usually a good idea to only allow a selected group of the application users to create and manage these records. In the GWApps templates we use a role called App Admin for this purpose. If you do use such a role, be sure to add your other roles in as readers on the look-up records so that normal users will be able to see those records and hence see the values in the list selection fields on the main forms.