Roles

> Customization > Application Roles

Roles are categories of users. Permissions can be assigned to a role. Then, as individual users move into and out of those roles, they acquire or drop the associated permissions.

About Roles

Your organization will be more effective when your users can get the information they need, when they need it. Sales representatives use data differently than marketing managers, VPs, CEOs or the folks in accounting. For example, a sales rep making cold calls needs a telesales application with activity logging capability, while a senior manager presenting to staffers may need structured, summary reports to manage overall business goals.

In an organization, employees have authority over information in different areas - they play different roles in each situation. In the platform, parallel roles can be defined to automatically manage access to that data. The information each employee needs to perform a task becomes available, and can be shared with a team of employees.

When role based access permissions are defined, users get streamlined views and reports, and the ability to complete their work online, in one place, with no extraneous information to distract from their flow. Roles are intended to control access, but they also add needed structure.

Considerations

• The ability to manage roles is subject to the restrictions of the Permissions Hierarchy.
• Each role can include a combination of any of the following permissions:

• Create or Delete records for each Object in the application
• Update, Delete or View records owned by other Team members

• Users can be assigned multiple roles in the same application.

• By default, a user acquires the combination of privileges defined in those roles.
• If the Switch User Roles setting has been selected in Company Information, then a user who has multiple roles can occupy only one Role at a time.

Learn More

• Default Roles
• User, Team and Role Guidelines

Default Roles

The out-of-the box implementation includes a default role, to get you started.

Role	Access Permissions
Manager	By default, a manager has full permissions to create and delete records in application objects, and has full access to records owned by other team members.

Learn more: Access to Records Owned by Others Within the Team

Custom Roles

Additional roles can be added and existing roles can be modified as the needs of the organization change. Note that Visibility Controls are an extension of Roles, and also affect the data that is available to users.

For example, a Web Tab can be created that is only available to managers.

Roles and Data Visibility

Standard Access Controls

A user's access to data is normally determined by a number of factors, shown here. It is also possible to define custom access criteria, described subsequently.

• The user's Access Profile specifies global access permissions and administrative permissions.

• The Application Access settings determine which applications the user can run. The Objects available to the user are therefore the combination of

a. Objects that are part of the running application

b. Objects that are shared from other applications.

• The user's Role in the application, as specified by the Application Access settings, specifies high-level access rights to individual application objects.

• The privileges granted in Access Profiles and Roles are additive. If either the Access Profile or the user's Role grants permission to perform some operation on an object, then the user has that permission.
• By default, Role privileges are additive, as well. If a user has been assigned multiple roles in an application, then the user has the sum of the privileges accorded to those roles.
• If the Switch User Roles capability is turned on, then the user has the ability to select which role is active, and has the privileges accorded to that role.

• The Team the user belongs to, and the access to records owned by other team members, as determined by the user's Role.

• Record Level Visibility can be used to restrict the visibility of individual records to a specified audience.

• Team Data Sharing Policies, which allow data to be shared across Teams. (These settings override the record-level access permissions specified in the individual's Visibility Controls.)

• Field Visibility, when used, specifies data visibility at the Field level.

• Task-based access allows access to records that may not otherwise be visible:

• Users who own a Task, or whose team owns the task, can view the record the Task is attached to.
• If the Task has open ownership, the record the Task is attached to can be viewed by anyone, for as long as the Task is unassigned.
• When a Process Task specifies that the task is to be closed with an accompanying Form, the user can view and edit record the Task is attached to while they are completing the task.
• When user lacks permission to view an object, they will be able to view the record in that object by following a link to it (for example, in the task's Related To field). They also see the record when completing the task. But there is no tab for viewing other records in that object, and a search will not reveal it.

Role Permissions

These are the permissions that can be specified for a role:

Record Access Permissions

For each object, specify the ability to Create, and Delete records.

If Record Level Visibility is enabled for an object, specify the ability to Control Visibility.

(In general, the ability to access an object implies the ability to view any of the records it contains. However, if Record Level Visibility is enabled, a role can also specify the ability to set visibility criteria for individual records, in order to restrict visibility of that record to a designated audience.)

Access to Records Owned by Others Within the Team

Specify the ability to Update, Delete, and View records contained in a each object.
(These permissions apply to records owned by a different member of the team.)

Custom Access Controls

Custom Access Criteria can be defined, as well. Those criteria can evaluate field values and apply functions to return true or false for different kinds of actions that can be taken on a record.

For example, records with a salary in excess of a certain amount can be made available to designated roles, only.

User, Team and Role Guidelines

In conjunction with Access Profiles, the combination of Team and Role assignments controls the user's ability to view and access data.

• Users

• Users can be members of multiple Teams
• When users are given access to an application, they are assigned one or more Roles

• Roles

• Roles are defined for applications
• Roles define the types of data users can access and share with other team members
• Default Roles are available in the platform
• Additional roles can be created and the default roles can be modified as needed

• Teams

• Each user must be assigned to a Primary Team.

Working with Roles

Application users generally fall into categories, or roles. A person in a given role needs permissions to work with some kinds of data, but typically doesn't need to work with other kinds data (or even see it).

It is common for new roles to be added over time, and for existing roles to evolve as the organization grows and business procedures are refined.

Users that have the Access Control permission can manage user roles..

Add or Edit a Role

To add or edit a Role:

1. Click > Customization > Application Roles
   The roles defined for the current application are listed.
2. Click the [New Role] button to add a role;
3. Optionally, click an existing role to edit the role
4. Specify the Role Settings (described below)
5. Click [Save]

Note:
The System Administrator role comes with the platform.

Clone a Role

You can clone a role in order to save time in creating a new role that has similar settings.

To Clone a Role:

1. Click > Customization > Application Roles
2. Click the name of the role you want to clone. The detail page for that role opens.
3. Click the [Clone] button.
   The Add Role page opens, displaying the settings from the Role you cloned.
4. Specify the Role Settings (described below)
5. Click [Save]

Delete a Role

To Delete a Role:

1. Click > Customization > Application Roles
2. Click the name of the role you want to delete; the detail page for that role opens
3. Click the [Delete] button at the top of the page.
   A confirmation dialog appears.
4. Click [OK] to delete the role.

Assign Roles to Users and Groups

In the Application Access settings, an administrator specifies which applications a user or group can access, and which Role(s) they assume in those applications.

Considerations

• If a user or group is assigned multiple roles, they have the privileges defined in all of them. (Their set of privileges is the sum of the privileges specified in the assigned roles.)

Role Settings

Role Information

Name

The name of the role as it will appear in the platform

Description

Text that describes this role and its settings (permissions)

Role Permissions

These are the permissions that can be specified for a role:

Record Access Permissions

For each object, specify the ability to Create, and Delete records.

If Record Level Visibility is enabled for an object, specify the ability to Control Visibility.

(In general, the ability to access an object implies the ability to view any of the records it contains. However, if Record Level Visibility is enabled, a role can also specify the ability to set visibility criteria for individual records, in order to restrict visibility of that record to a designated audience.)

Access to Records Owned by Others Within the Team

Specify the ability to Update, Delete, and View records contained in a each object.
(These permissions apply to records owned by a different member of the team.)