Creating Permission Groups

A permission group is a group of object permissions. Permission groups can be assigned to individual users or roles. A permission group is a label or tag that can be assigned to object permissions rather than a separate physical object. As a result, object permissions with the same permission group label can be assumed to be part of the same permission group. The best practice suggests keeping object permissions granted to a single permission group.

You can also assign out-of-the-box (OOTB) permission groups to control which applications non-admin users can see on the Conga Platform. For example, if you want your non-admin users to see and use only the Revenue Apps, you can assign them the Conga CPQ Permission Group.

An object permission specifies the various levels of access or restrictions that a user has on a given object. Using object permission, you can allow or restrict a user from viewing or modifying all instances of an object. In addition to the object permissions, you can also limit user access to specific fields within an object. This ensures that users have access only to the data they need, improving security and compliance within the system.

If a user is restricted from viewing and modifying object records, you can still grant access to some instances via Scope Permissions. Through Action Permissions, you can further control whether a user has access to perform specific actions (standard actions like create, read, update, delete, or custom actions like generate, activate, and so on). Object permissions include both Scope and Action Permissions.

For any given object, the user’s permissions are considered to access the application as per the steps below:

1. Object Permissions: To evaluate the user’s permission on any object, View All and Modify All attributes in object permission are used. If these attributes are true, the user has full access to all the instances of the object. If only View All is true, the user can access all the object records but can’t create, update, or delete the records.

2. Read Criteria: When Modify All object permission is not set, you can add the read criteria to filter the data and return only records matching the criteria. Users can also see the records that are shared with them. The table below summarizes a few examples based on specific conditions, showing what users are allowed to see in each scenario:
   

   Condition	Read Criteria	Scope & Record Sharing	Description
   ViewAll = true, ModifyAll = false, Read = true	Status = 'Request'	Not provided	Users can view records associated with the status request and records that are shared with them.
   ViewAll = true, ModifyAll = false, Read = true	Not provided	Not provided	Users can view all records.
   ViewAll = false, ModifyAll = false, Read = true	Status = 'Request'	Global Scope: Status = In Review User Scope: [ { "RelationShipFieldName = "ContractFacilitator" }]	Users can view records matching any of the following criteria: Status is Request. Status is In Review. The current user is the Contract Facilitator. The record is shared with them. The owner of the record.
   ViewAll = true, ModifyAll = true, Read = true	Status = 'Request'	Not provided	Users can view records associated with the status request and records that are shared with them.

3. Action Permissions: In addition to the standard CRUD actions, you can assign custom object-specific actions. Aside from standard CRUD operations, we have some agreement lifecycle actions like GENERATE, ESIGN, ACTIVATE, AMEND, and so on for Agreement objects. Using the Action Permission option, you can assign any or all of these actions.
4. Field Permissions: In addition to the object permission, you can define and enforce access permissions at the field level for different user roles. Read Only and Edit attributes are used to control each field-level access control for the given object. 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.
   
   

   You cannot change the access control for system-generated fields (Created By, Created Date, Modified By, and Modified Date).

   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.

5. Record Type Permissions: In addition to the object and field level permissions, you can 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 and viewing records. 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.
6. Scope Permissions: When both View All and Modify All object permissions are not set, the user cannot access any object records. However, you can grant READ access to some records using scope configurations. The following are the three levels of scope configuration that you can set:
   

   • Global Scope: 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 are present in the schema.

   • User Scope: Allow users to access a record if the 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 should be an attribute in the Agreement object.
     

     

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

   • Account Scope: The admin can allow the user (record owner or who created the account record) 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 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.

To create a Permission Group

1. Log in to the Conga Platform as an admin user.
2. Click the App Launcher () icon from the top-left corner > Admin Console > Users.
3. Go to the Permission Groups tab and click Add New.

4. Enter values in the following fields:

   Field	Description
   Display Value	Enter the display value (name) that is displayed as a name in the list view.
   Value	Enter the unique value (name) for the permission group. You can enter up to 80 characters in this field.
   Description	Enter a description of the permission group.

5. Click Save.

You can see the newly created permission group in the list view.

• The application automatically adds the View All permission to the AppRegistry object, allowing non-admin users to view the Conga Platform Admin Apps. However, you can change the object permission if necessary.
• To delete the Permission Group, Click the More () icon at the start of the record and click Delete. If the respective Permission Group is assigned to any User or Role, you will receive the validation message and will be unable to delete it.

To assign Object Permission

1. Click the permission group name link from the list page, or click the more () icon at the start of the record and click Edit.

2. On the Object Permissions tab, click the Add Object Permissions button.

   

   The system automatically generates the "customcode" and "Configuration" object permissions upon the creation of a permission group.

3. Search and assign the required permission for the Object(s).
   • Modify All: Select this option to automatically grant all standard CRUD (Create, Read, Update, Delete) action permissions.
   • View All: Select this option to grant Read permission by default.
   • CRUD Actions: Manage individual permissions for standard CRUD operations (Create, Read, Update, Delete).
   • Read Criteria: Click the Set link in the Read Criteria column to set access criteria for specific objects. Use only queryable fields from the object to set the criteria.
   • Custom Action Permissions: Control which custom actions (e.g., activate, generate) users can perform. Click the Set link in the Action Permissions column to assign custom actions to specific objects.
     The table below summarizes user permissions based on specific conditions and actions, showing what users are allowed to do in each scenario:
     

     Condition	Action	User Permission
     ViewAll = false, ModifyAll = false, Create = true	Create	User can create a record.
     ViewAll = false, ModifyAll = false, Update = true	Update	User can update records only if they: Own the record, or Have edit access to a shared record. The system throws a validation error if the user attempts to update a record accessible through permissions other than owner scope (global/user/account).
     ViewAll = false, ModifyAll = false, Delete= true	Delete	User can delete records only if they own them. The system throws a validation error if the user attempts to delete a record accessible through permissions other than owner scope (global/user/account).
     ViewAll = false, ModifyAll = false, Read= true	Read	The user can view a record if any scope (global, user, or account) grants access, if they own the record, or if it is shared with them.

4. Click Save Object Permissions.

To delete the Object Permissions, select the object(s) from the list and click the Delete Object Permissions button.

To assign Field Permission

1. Click the permission group name link from the list page, or click the more () icon at the start of the record and click Edit.

2. On the Object Permissions tab, navigate to the respective object and click the Set link in the Field Permissions column.

3.  Apply the Edit and Read Only access to the respective fields. By default, all fields within an object have full access (both Read and Edit).
   This table outlines the various access levels and their corresponding permissions for grid and detail views.

   Access Level	Grid View	Detail View
   Edit	Displays an edit icon next to the field value, allowing inline editing directly from the grid.	Shows an edit icon next to the field value, allowing edits.
   Read-Only	Displays a lock icon next to the field. A validation message appears on hover when edit is attempted.	Field is disabled. A message appears on hover when interaction is attempted.
   None (No Read or Edit Access)	The field is not displayed in the grid.	The field is not displayed in the record detail view.

   

   You cannot change the access control for system-generated fields (Created By, Created Date, Modified By, and Modified Date).

4. Click Save.

To assign Record Type Permission

1. Click the permission group name link from the list page, or click the more () icon at the start of the record and click Edit.

2. On the Object Permissions tab, navigate to the respective object and click the Set link in the Record Type column.

3.  Assign access to the respective record field. By default, all record types are accessible to all users who have access to the object.

4. Click Save.

To add Scope Permissions

• Global and User scopes are only applicable when ViewAll/ModifyAll is not set up for the particular object.
• Only queryable fields are used to set read criteria for all global and user scops.

1. Click the permission group name link from the list page, or click the more () icon at the start of the record and click Edit.
2. Go to the Global Scope, User Scope, or Account Scope tab.
3. Set the criteria and click Apply.