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): An object permission defines different levels of access or restriction for a user on a given object. A user can have object permissions through permission groups. You can use object permissions to allow or restrict a user from viewing or modifying all instances of an object. If a user is restricted from viewing and modifying object records, you can still allow access to some of the instances through scope permissions. You can further control whether the user has access to perform certain actions (standard actions like create, read, update, delete, or custom actions like generate, activate, etc.) through action permissions. Both scope and action permissions are part of object permissions.
  • Permission Group: A permission group is a collection of object 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 ObjectPermission contains access details for one object for a permission group.

    1. To evaluate the user’s permission on any object, start by checking the ViewAll and ModifyAll attributes in object permission. If these attributes are true, the user has full access to all the instances of the object. If only ViewAll is true, the user can access all the object records but can’t create, update, or delete the records. ModifyAll can’t be true if ViewAll is false.

    2. If both attributes (ViewAll and ModifyAll) are false, the user has no access to any object records by default. You can, however, give access to some of the records through scope configurations. You have different levels of scope configurations as part of the ScopePermissions attribute in ObjectPermission.

      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 index 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 indexed, 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. If you want 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.

      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, you need to 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 create entries in the Agreement_UserShare object so that recipients can access the agreement record shared with them. 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.

        {
    "Id": "4c2a762c-3242-4768-89ab-a39aeefe1734",
	"Name": "4c2a762c-3242-4768-89ab-a39aeefe1734",
	"ObjectId": "3D9939AF-A298-EA11-86E9-2818786A0810",
    "UserId": "02631c5b-b1b9-4a5e-b7e5-9f5805e69536",
	"AccessLevel": 0,
	"CreatedDate": "2021-07-21",
	"ModifiedDate": "2021-07-21",
	"CreatedBy": { "Id": "802e9a13-5e5b-4c96-92ab-820cf385b620", "Name": "System Admin" },
	"ModifiedBy": { "Id": "802e9a13-5e5b-4c96-92ab-820cf385b620", "Name": "System Admin" }
  }
        CODE

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

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.