Understanding Role-Based Access Control

Conga supports role-based access control (RBAC) to restrict access to various applications and data within the Conga Revenue Lifecycle Platform. Conga RBAC supports data access through the following primary means of enforcement:

• Object Permissions (OP): Object permissions define the level of access or restriction a user has to a specific object. These permissions are usually granted through permission groups. You can use object permissions and read criteria to allow or restrict users from viewing or modifying all instances of an object. Additionally, you can control which actions users can perform, whether they are standard actions (like create, read, update, delete) or custom actions (such as activate or generate). Even if a user is restricted from viewing or modifying object records, you can grant access to specific instances through scope permissions. Both scope and action permissions fall under object permissions.
• Record-Sharing Behavior: If you have not granted Modify All, View All, or action permissions (Read or Update) from the object permissions, and if a user shares a record with another user using the Record Share facility, the application allows the user to modify or view that specific record based on the permissions provided when the record was shared. To learn more about sharing a record, see Sharing Records with Users.
• Field Permissions: A field permission allows administrators to define and enforce access permissions at the field level for different user roles. This ensures that users have access only to the data they need, improving security and compliance within the system. Field-level access control enables administrators to limit user access to specific fields within an object.
  Benefits include:

• • Enhanced Data Security: By restricting access to sensitive fields, RBAC for fields helps protect critical information from unauthorized access or modification, reducing the risk of data breaches.
  • Improved Compliance: RBAC ensures that only authorized personnel have access to certain data, which is essential for meeting regulatory requirements and maintaining compliance with data protection laws.
  • Tailored User Experience: Users only see and interact with the data they need, which simplifies their workflow and reduces the risk of errors by preventing them from accessing irrelevant or sensitive fields.
  • Flexible Control: The ability to set different access levels for different fields allows for granular control over data access, ensuring that permissions can be tailored to meet the specific needs of different teams and roles within the organization.

For instance, if you have a Contract object with ten fields, you can configure the system so that certain user groups or roles can only view or edit specific fields while being restricted from others. For example, consider a scenario where a Contract object has fields like "Contract Name," "Amount," "Close Date," "Client Name," and others. You might want the Legal Team to monitor the contracts but not edit them. Using RBAC for fields, you can restrict the Legal Team to read-only access for "Contract Name," "Amount," and "Close Date," while preventing access to more sensitive fields like "Client Name" and "Internal Notes."
This table outlines the various access levels and their corresponding permissions for grid and detail views:

Field-level access control is managed through Permission Groups > Object Permissions. By default, all fields within an object have full access (both Read and Edit) for all users. However, administrators can customize these settings to restrict access as needed.

For custom object layouts created via CX Studio, field-level edit permissions set in CX Studio take priority over general permission group access. Even if your role's Permission Group provides Edit access at the field level, you will not be able to edit values in the grid view columns or the record detail view fields unless they are explicitly set as “Editable” in the CX Studio layout properties. For more information, see Managing Data Grid View and Managing Content Details View.

• Record Type Permissions: A record type permission allows administrators to define and enforce access permissions at the record type level for different user roles. This ensures that users have access to specific record types when creating records. For instance, if an Agreement object contains two record types—Non-Disclosure Agreement (NDA) and Master Services Agreement (MSA)—an administrator can configure the system so that:
  • All users can create records using the NDA record type.
  • Only users with specific roles (e.g., Legal Team or Contract Managers) can create records using the MSA record type.
    
    

    Record Type level access control is managed through Permission Groups > Object Permissions. By default, all record types within an object are accessible to all users who have access to the object. However, administrators can customize these permissions as needed.

• Permission Group: A permission group is a collection of object permissions and field permissions. Permission groups can be assigned to individual users or roles. A permission group is not a separate object but rather a label or tag that can be assigned to object permissions. So object permissions having the same permission group label can be assumed as part of that permission group. Object permission must not belong to more than one permission group.
• Role: The role represents a profile (e.g., system admin, contract facilitator, general user, etc.). A role will contain at least one permission group; however, it can be extended to have multiple permission groups depending on the use case.
• User: The user is an individual identity with predefined access to the system depending on its role. A user can have only one role but can be assigned additional permission groups if needed. So the user will be getting at least one permission group through the assigned role. User access will be evaluated as a union of all the object permissions obtained through permission groups.
• Access Resolution at Runtime: A user gets different permissions through the role and permission groups assigned to it. Logging into the application resolves the user's role, determining the associated permission group. Users may have additional permission groups assigned. User permissions are evaluated as a union of all object permissions coming from all the permission groups.

  For any given object, the user’s permissions are resolved per the steps below. One record in Object Permissions contains access details for one object for a permission group.

  1. To evaluate the user’s permission on any object, start by checking the View All & Modify All attributes, and Read Criteria in object permission.

     • If the Modify All is true, the user has full access (as per the Read Criteria) to all the instances of the object.

     • You can also control which actions users can perform, whether they are standard actions (like create, read, update, delete) or custom actions (such as activate or generate).
  2. Even if a user is restricted from viewing or modifying object records, you can give access to some of the records through scope configurations. You have different levels of scope configurations as part of the Scope Permissions attribute in Object Permissions.

     1. Global Scope: The admin can allow users to access object records based on some criteria. For example, you can configure access to all the agreements that are non-confidential.

        

        Criteria fields must be queryable fields that exist in the schema.

        "ScopePermissions": {
        			"GLOBAL": "Account.Name='Conga' AND RecordType='MSA'",
        			"USER": [],
        			"ACCCOUNT": "",
        			"CONTACT": ""
        		}

        CODE

     2. User Scope: The admin can allow the user to access a record if a user is tagged as an attribute value on the object. For example, a user can access an agreement if he is the contract facilitator of the agreement. The contract facilitator will be an attribute in the Agreement object. You can also have additional criteria similar to Global scope.
        

        

        The relationship field must be a lookup field that is queryable, and the lookup object name must be the User object.

        "ScopePermissions": {
        			"GLOBAL": "",
        			"USER": [{"RelationshipFieldName": "ContractFacilitator", "Criteria": "Account.Name='Microsoft'"}],
        			"ACCCOUNT": "",
        			"CONTACT": ""
        		}

        CODE

     3. Account Scope: The admin can allow the user (who created the account record or record owner as an individual user or part of the user group) to access a record if an account is tagged as an attribute value on the object. For example, an agreement has two fields, PrimaryAccount and SecondaryAccount, both of which have a lookup relationship to the Account object. To consider the PrimaryAccount field for resolving account scope, specify the PrimaryAccount field while setting up the account scope for the Agreement object. Assume there is an Agreement Record (ARecord1) with account1 as the primary account. You can only access ARecord1 if you are the owner of the account1, part of the user group associated with the account1, or created it.

        

        To use account scope on any object, you must enable the Is Allow Owner Scope toggle for the Account object. For more information on owner scope toggle, see Creating and Managing Objects.

        "ScopePermissions": {
        	"GLOBAL": "",
        	"USER": "",
        	"ACCCOUNT": {"AccountScopeFieldName": "PrimaryAccount"},
        	"CONTACT": ""
        }

        CODE

     4. Owner Scope: The owner of the record will have access to the record automatically. 

        

        To use owner scope on any object, you must enable the Is Allow Owner Scope toggle for the object. For more information on owner scope toggle, see Creating and Managing Objects.

     5. Participants and Child Scope: A user can be added manually as a participant in an object record or can have access to a record through child scope. Both of these scopes are enabled using Object sharing. In order to make an object shareable, set the IsShared flag to true while defining the object. To store the shared records for an object, the application automatically creates a new object with the naming convention [ObjectName]_UserShare (e.g. Agreement_UserShare) when it is marked as shared. Any application-specific process like eSignature can share the record with recipients through record sharing. New entries can be created manually to enable participant sharing. You can also configure the access level for the shared records. You can set the value as 0 for read-only access and 1 for edit access.

  3. The user can perform different actions on an object record through the standard CRUD actions and you can have custom object-specific actions as well. For example, you have some lifecycle actions like GENERATE, ESIGN, ACTIVATE, AMEND, etc. for agreement objects apart from standard CRUD operations. Admin can perform all these actions on an object that is defined as part of the ActionPermissions attribute in ObjectPermission. The user can perform an action only if that action is enabled in the object permission record associated with the user. Criteria-based action permissions can also be configured, either alone or as part of an action permission.

     

     Action permission criteria are only supported for READ action permissions.

     "ActionPermissions": {
     		  "CREATE": {
     			  "Standard": true,
     			  "Enabled": true,
     			  "Criteria": ""
     		  },
     		  "UPDATE": {
     			  "Standard": true,
     			  "Enabled": true,
     			  "Criteria": ""
     		  },
     		  "DELETE": {
     			  "Standard": true,
     			  "Enabled": false,
     			  "Criteria": ""
     		  },
     		  "READ": {
     			  "Standard": true,
     			  "Enabled": true,
     			  "Criteria": "Account.Name='Conga'"
     		  },
     		  "GENERATE": {
     			  "Standard": false,
     			  "Enabled": true,
     			  "Criteria": ""
     		  },		  
     		  "AMEND": {
     			  "Standard": false,
     			  "Enabled": true,
     			  "Criteria": ""
     		  },
     		  "RENEW": {
     			  "Standard": false,
     			  "Enabled": true,
     			  "Criteria": ""
     		  }
     		}

     CODE

The system evaluates record type access at runtime during access resolution. For more information on how to work with Roles and Permission Groups, see Creating Roles, Creating Permission Groups, Working with Roles, and Working with Permission Groups.