Roles control the data that users can create, edit, delete, view, or manage in Core by adding individual users or user groups to a role, selecting the object type(s) those users can see, applying either global or explicit permissions, then configuring the workflow permissions for each object type added to the role. If needed, you can review which roles a user has been added to from the User Role Membership section on the Edit User page.
 | Roles determine a user's eligibility to access objects only. Removing a user from a role with explicit permissions after they've been granted direct access to an object does not automatically revoke their access to that object. Another user with the appropriate permissions must revoke access by removing the user from the role field on the object's form. |
The Edit Role page.
Global Permissions
Global permissions grant users access to all the objects that belong to the object type(s) added to that role, however, you can control what rights they have (Create, Read, Edit, etc.) and which configurable form is displayed in their tasks and Quick Add, based on the current state of the object.
Explicit Permissions
Explicit permissions grant users access to specific objects that belong to the object types added to the role. Before a user can see those objects, the role must be added as a component on the object type and configurable form, then the user must be selected in the role field on the form, which grants them direct access to that object. You can control what rights those users have (Create, Read, Edit, etc.) and which configurable form is displayed in their tasks and Quick Add, based on the current state of the object. You may also need to configure inferred permissions for roles with explicit permissions enabled.
If a user with explicit permissions on an object type can’t see one or more objects, ensure that user has been granted access to the object(s) via the Role element on a form. See the Roles on Forms section for more information. Note that only users with Manage permissions can grant other users access to existing objects. See Workflow Permissions for more information.
Example
| EXAMPLE |
| Kevin Darden is a manager at your organization, so his role, Incident Reviewer, has been given global permissions so he can read, edit, and manage all Incident objects throughout the workflow. Hollie Peel is a non-managerial employee who may have to create Incident objects, but doesn't need to view or edit existing objects, except under special circumstances, so she’s put in the Incident Creator role which has Create and Read permissions only, as well as the Incident Reviser role, with Read and Edit rights. With the Incident Reviser role added to a configurable form, Kevin can add her to an existing object to grant her permission to add or revise information, however, she won’t have permission to access other existing objects until a user from the Incident Reviewer role adds her to the role field on those objects. |