Introduction to Roles

Overview

Roles are used to control access to modules and the fields within those modules. Users belonging to a particular role will have the ability to access increased or reduced functionality depending on the module- and field-level changes made within the role. By default, users who are not assigned to a role can access and perform actions in any enabled module.

Sugar includes team security in addition to roles. Team membership determines which records a user is allowed to see, while role membership determines module availability and what a user can do with the records he can see. For more information, please refer to the Role Management and Team Management documentation.

Enabling or Disabling Module Access

You can set one of the following module-level access options when you create a role:

Not Set: (default) Ensures that the role does not affect a particular setting.
Enabled: Permits the user to view the module.
Disabled: Hides the module from the user's view.

Setting High-Level Module Access Permission Types

For a role's enabled modules, Sugar provides different access types. These access types are as follows:

Normal: Allows users to view and manage records depending on team membership. Regular users are usually granted Normal access type.
Admin: Allows users to administer all records in the specified module regardless of team membership. However, the user does not have access to developer tools such as Studio and Workflow Management.
Developer: Allows assigned users to access Developer tools in Sugar, namely Studio, Workflow Management, and Dropdown Editor, which are required to customize a module. However, appropriate team membership is still required to view records in the module.
Admin & Developer: Allows users to not only view and manage all records in the module(s) but also access to administration and development tools available to manage them. The user does not require team membership to view records in the module. Sugar provides the following set of pre-defined Admin & Developer roles for your use:
- Customer Support Administrator: Administrator and developer access to Accounts, Bug Tracker, Cases, Contacts, and Knowledge Base
- Marketing Administrator: Administrator and developer access to Accounts, Contacts, Leads, Campaigns, Targets, and Target Lists
- Sales Administrator: Administrator and developer access to Accounts, Contacts, Forecasts, Forecast Schedule, Leads, Opportunities, and Quotes
- Tracker: Access to the Tracker module and pre-defined and custom Tracker reports

Configuring Module-Specific Activity Permissions by User Relationship

Common activities can be restricted by the user's relationship to the records within an enabled module. Permission for each activity may be restricted to the following user relationships:

All: All users who are assigned to the role.
Owner: The user assigned to the record.
None: Nobody can perform the action.
Not Set: Ensures that the role does not affect a particular setting. That is, the role allows the action.

The module-specific activities controlled by the above user relationships are:

Delete: Regulates a user's ability to delete records. If "None" is selected, users assigned to this role will not see the Delete button on record views and list views for the relevant module.
Edit: Regulates a user's ability to edit records. If "None" is selected, users assigned to this role will not see the Edit button on record views and list views for the relevant module, and the user will not be able to mass update from list views.
Export: Regulates a user's ability to export complete database records. If "None" is selected, the Export option in the list view Actions menu for the relevant module will be hidden from users assigned to the role.
Import: Regulates a user's ability to import new records or updates to existing records. If "None" is selected, option in the relevant module's Actions menu will be hidden from users assigned to the role.
List: Regulates a user's ability to see list views in the relevant module.
View: Regulates a user's ability to see complete record views in the relevant module.

Using Roles for Field-Level Access Control

You can use roles not only to restrict access to a module but also restrict access to specific fields within a module. A use case for this field-level access control would be a role that is restricted from viewing an opportunity's Amount field so that people outside the sales department can not access this potentially sensitive information. You can set field access to Read Only or hide it completely for a particular role.

Not Set: Ensures that the field-level access control does not affect a particular setting.
Read/Write: Users will have permission to view and edit this field.
Read/Owner Write: Users will have permission to edit this field only if they are the record's assigned user. Otherwise, they can view the field but not edit it.
Read Only: Users can see the value of this field but they cannot edit it.
Owner Read/Owner Write: Users will have permission to view and edit this field only if they are the record's assigned user.
None: This field will be hidden from the user's view altogether.

Assigning Multiple Roles to a User

When a user belongs to multiple roles, the more restrictive setting prevails. For example, if a user is assigned to one role that restricts deleting accounts, and the same user is also assigned to a role that permits deleting accounts, the user will not be able to delete accounts because Sugar recognizes the most restrictive aspects of each assigned role. Access permissions for a particular user are displayed on their Sugar Users module record view.