Roles and permissions

A user has all permissions assigned to that user's assigned role. In addition, you can assign individual permissions to a particular user. See User-based access control for more information.

You can assign the following permissions by role:

Permissions to access selected applications.
- If a particular role has access to an application, that role will be given default access to newly created components of that application unless you override this access.
  Note: In the event that the target tenant has additional roles or permissions configured that do not exist in the application being installed, utilizing the Override Permissions option will result in the removal of these permissions on the target tenant to align with the application's settings upon deployment.
- If a particular role does not have access to at least one application, and at least one tab in that application, a user with that role will not be able to log in to Platform.

Permission to access the following object definition pages, including view, create, edit and delete permissions per object type. The following table details every permission required to perform each page-type action.

Page Type Action	Users / Roles need the following access to the parent object
View	VIEW
Edit	EDIT
New	CREATE
Search Results	VIEW
Status Change	EDIT
Selector	VIEW
Mass Update	EDIT
Quick Create	CREATE
Records List	For roles associated with any Tab or Menu VIEW access is required for both the parent object AND the tab/menu. For roles not associated with any Tab or Menu Make sure VIEW access is available to the parent object.

Permission to view object fields in the user interface, and the ability to specify that a field is read-only in the user interface for particular roles. For API access, permissions for fields are determined by permissions for the object type.
Permission to access views, tabs, charts, reports, and workflow actions.
Permission to access menus, including submenus.

Administrative permissions that can be granted to any user-defined role (but not non-administrative system roles):

Permission	Granted by default
Manage (create, modify and delete) views	No
Manage (create, modify and delete) charts	No
Manage (create, modify and delete) reports	No
Manage (create, modify and delete) templates	No
Manage currency exchange rates	No
Send individual and mass emails	Yes
Use Print, PDF, and Spreadsheet export links	Yes
Convert records to different object type	Yes
Merge multiple records into a single record	Yes
Manage (create, modify and delete) import maps	Yes
Manage Roles	No
Manage Security Settings (authentication and whitelist)	No
Manage Monitoring (monitor setup, system jobs, user sessions, portal visitors, system logs, and support access sessions )	No
Manage Currency Codes	No
Manage Email Server Settings	No
Manage Customer Preferences (preferences and localization settings)	No
Manage Backups	No
Manage Global Text Search	No
Manage Users	No
Configure Support Access	No
View Integration Password	Yes

Note the following about the above administrative permissions:

Merge and convert functionality also require permission to create a new record of the selected object type. Objects include system entities that can be used in reports, such as activity trails, comments, and login history records.
When a role is granted the Manage Roles permission, users with that role can create and edit roles. They can only create roles with the same set of permissions as their own role or with a subset of those permissions. They cannot manage the Administrator role or their own role. They cannot assign any administrative permissions to any role.
When a role is granted the Manage Users permission, users with that role can edit users if they have the appropriate permissions on the User object. They cannot assign the Administrator role to a user.
When a non-administrative role is granted the View Integration Password permission, they can view the password field values in plain-text for REST, SOAP, and AJAX calls. If no permission is granted, the password field value is returned as Password on File.
This permission can’t be granted to non-administrative system roles – Portal User and Portal Guest. This permission does not apply to Server Side APIs or field tokens used in template/trigger body. They always return password as plain-text value.
When a non-administrative role is granted the Search Box permission, they can view the search button. If no permission is granted, the search button is not enabled for users with that role.
This permission can’t be granted to non-administrative system roles – Portal User and Portal Guest.
Until Platform 6.5, if an Administrator role has View permissions (say, Charts/Reports) and no other roles had this permission, users of all roles were able to view the charts/reports. In Platform 6.5, only a user in a role that has explicit View permission will be able to view the charts/reports.
Until Platform 6.7, the users of all roles can view, create, update & delete the templates. However in Platform 6.8, only the user who explicitly has View permission in Manage Templates is able to create, update or delete the templates.
Access control permissions are established at the role level. In the usual scenario, if a user holding a particular role tries to access pages without the necessary permissions, the application displays an error message through a growl notification. Subsequently, the user is also redirected to the Landing Page as configured in the User Preferences section.
In some instances, the user may be sent to an error page rather than the configured landing page. This error page is included with navigation panes which enable the user to navigate onto the desired page.
In the event that a landing page is not configured in the designated application or if the primary tab is inaccessible or invalid, the system will smoothly default to the first accessible application for the user or the left-most/first tab within the same application.