Conga supports role-based access control (RBAC) to restrict access to applications and data within the Conga Advantage 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. See Sharing Records with Users for more.

• 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 in the system. Field-level access control enables administrators to limit user access to specific fields in an object.
  Here are some (not the only) key points that highlight benefits:

  • 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 in 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 access levels and corresponding grid and detail view permissions:

• 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.
    Note:

    Record-type-level access control is managed through Permission Groups > Object Permissions. By default, all record types in an object are accessible to all users with 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 permissions cannot belong to more than one permission group.
• Role: The role represents a profile (e.g., system administrator, contract facilitator, general user, etc.) A role must contain at least one permission group.
• User: The user is an individual identity with predefined system access depending on its role. A user can have only one role but can be assigned additional permission groups if needed. The user thus gets at least one permission group through the assigned role. User access is evaluated as the union of all object permissions obtained through permission groups.
• Access Resolution at Runtime: A user gets different permissions through the role and permission groups assigned to them. 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 following the steps below. One object permission record contains access details for one object for a permission group.

  1. To evaluate the user's permission on any object, check the View All & Modify All attributes, and Read Criteria in the object permission.
     • If Modify All is true, the user has full access (per the read criterion) 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. The Scope Permissions attribute in Object Permissions offers these scope configuration levels:
     1. Global Scope: The administrator can grant users criteria-based access to object records. For example, you can configure access to all non-confidential agreements.
        Note:

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

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

     2. User Scope: The administrator 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.
        Note:

        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": ""
        	}

     3. Account Scope: The administrator 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.
        Note:

        To use account scope on any object, enable the Is Allow Owner Scope toggle for the Account object. For more information on the Allow Owner Scope toggle, see Objects.

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

     4. Owner Scope: The record's owner has access to the record automatically.
        Note:

        To use owner scope on any object, enable the Is Allow Owner Scope toggle for the object. For more on the 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. To make an object shareable, set the IsShared flag to true while defining the object. To store 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. In addition to the standard CRUD actions, a user can perform custom object-specific actions on an object record. For example, you have configured such life-cycle actions as GENERATE, ESIGN, ACTIVATE, AMEND, etc. for agreement objects in addition to standard CRUD operations. The administrator can perform all these actions on an object 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.
     Note:

     Action permission criteria are only supported for Read action permissions.

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

The system evaluates record type access at runtime during access resolution. For more, see Roles and Permission Groups.