Managing Roles and Permission Groups

Role and Permission Group management helps administrators configure security on the Conga Platform. A role represents a profile (for example, system admin, contract facilitator, general user, and so on). Administrators can create user roles that contain a set of permissions with specific access to objects, records, pages, and administrative functions in applications built on the Conga Platform. You can use the User Interface or REST APIs per your business needs. 

The following topics are covered in role and permission group management.

• Role-Based Access Control (RBAC): Conga supports role-based access control (RBAC) to grant or restrict access to various applications and data within the Conga Revenue Lifecycle Platform. Conga RBAC supports data access primarily through mechanisms such as object permissions, permission groups, roles, and so on.
• Permission Groups: A permission group is a group of object permissions. Permission groups can be assigned to individual users or roles. 
• Roles: A role is assigned to users performing similar tasks and consists of a set of permissions. As an administrator, you can assign roles to the existing users or create a new user and edit the user details to assign roles. 
• User groups: User Groups enable administrators to create groups of individual users with specific roles and permissions.
  

For more information, see Managing Roles and Permission Groups.

Object Permissions 

Object permissions define the level of access or restriction a user has to a specific object. These permissions are usually granted through permission groups. The Modify All and View All permissions grant users access to all records of an object. For example,  granting ModifyAll or ViewAll permissions on the Account or Contact object enables users to view or edit all records in the Account list page or Contact list page. To allow users to create, update, and delete records without needing Modify All or View All permissions, you can assign CRUD (Create, Read, Update, and Delete) permissions independently.

The following table lists a few permission levels that can be assigned to a CLM user for various objects.

Action Permissions

In addition to the standard CRUD operations, you can assign custom object-specific actions that can be set for CLM users. The following table lists a few of the action permissions (for example, such as Clone, Share, and so on).

Field Permissions

In addition to the object permission, you can define and enforce access permissions at the field level for different user roles. The following table lists some of the field-level permissions (for example, RecordOwner, RecordType, and so on) that can be set on an object for users.

Roles

A role is assigned to users performing similar tasks and consists of a set of permissions. As an administrator, you can assign roles to the existing users or create a new user and edit the user details to assign roles. You can also assign multiple permissions and permission groups to a user to grant access to all the assigned role permissions. For example, with the CongaCLMReadOnlyUser role, a user can view all records they have permission to see when navigating to the Search tab on the Contract Details page.

As an administrator, you can create roles to restrict access to data for certain users based on their functional roles and responsibilities. For instance, if a user is assigned the CongaCLMReadOnlyUser role and navigates to the Contact page, the options Create Contact, Edit, Delete, or Create Contract on the Details page are not displayed for that user.