Permission Groups
A permission group is a group of object permissions that can be assigned to individual users or to roles. Because a permission group is a label or tag assigned to object permissions rather than to a discrete object, object permissions with the same permission group label can be assumed to be part of the same permission group. It is a best practice to keep object permissions granted to a single permission group.
You can assign out-of-the-box (OOTB) permission groups to control the applications that non-administrative users can see on the Conga Advantage Platform. For example, if you want non-admin users to see and use only Revenue apps, you can assign them to the Conga CPQ permission group.
An object permission specifies the levels of access or restriction that a user has for 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 object permissions, you can limit user access to specific fields within an object, ensuring 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 such standard actions as create, read, update, delete; or custom actions such as 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 follows:
- Object Permissions: For any object, the View All and Modify All object permission attributes are used to evaluate a user's permission. 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 cannot create, update, or delete the records.
-
Read Criteria: When the Modify All object permission is unset, you can add read criteria to filter the data, returning only matching records. Users can also see the records that are shared with them. The table below offers a few examples of what users can see under 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.
- 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.
- 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 control each object's field-level access. By default, all fields in an object have full (both read and edit) access for all users. However, administrators can customize these settings to restrict access.Note:
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 cannot 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: 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 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.
- 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.Note:
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.Note:
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.Note:
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 Objects.
- 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.
Creating a Permission Group
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 Advantage Platform administration apps. You can change the object permission if necessary.
Assigning Object Permissions
To delete an object permission, select it from the list and click the Delete Object Permissions button.
Assigning Field Permissions
Assigning Record-Type Permissions
Adding Scope Permissions
Global and user scopes only apply to an object if ViewAll or ModifyAll is not set up. Only queryable fields are used to set read criteria for all global and user scopes.
- Log in to the Conga Advantage Platform as an administrative user.
- Click the App Launcher (
) icon in the top left corner, then .
- Click the Permission Groups tab.
- Click the permission group name link from the list page, or click the More (
) icon adjacent to the record and click Edit.
- Open the Global Scope, User Scope, or Account Scope tab.
- Set the criteria and click Apply.
Editing a Permission Group
After you create a permission group, you can view, update, or delete it from the list page. You can also search for specific records in the grid by performing a keyword search. For more information, see Filter Records in the Grid View.
To view permission group information, click the Permission Group Name link from the Permission Groups list page.
