Conga Product Documentation

Welcome to the new doc site. Some of your old bookmarks will no longer work. Please use the search bar to find your desired topic.

Show Page Sections

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.

Note:

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:

  1. 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.
  2. 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:
    ConditionRead CriteriaScope & Record SharingDescription

    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 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.

  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 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.
      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.

Creating a Permission Group

  1. Log in to the Conga Advantage Platform as an administrative user.
  2. Click the App Launcher () icon in the top left corner, then Admin Console > Users.
  3. Click the Permission Groups tab.
  4. Click Add New.
  5. 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.

  6. Click Save.

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

Note:

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

  1. Log in to the Conga Advantage Platform as an administrative user.
  2. Click the App Launcher () icon in the top left corner, then Admin Console > Users.
  3. Click the Permission Groups tab.
  4. Click the permission group name link from the list page, or click the More () icon adjacent to the record and click Edit.
  5. On the Object Permissions tab, click the Add Object Permissions button.
    Note:

    The system automatically generates the "customcode" and "Configuration" object permissions when creating a permission group.

  6. Assign the required permission for the object(s).
    • Modify All: Grant all standard CRUD (Create, Read, Update, Delete) permissions.
    • View All: Grant Read permission by default.
    • Read, Create, Update, and Delete: Manage individual permissions for standard CRUD operations.
    • 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.
    This table summarizes user permissions based on specific conditions and actions, showing what users are allowed to do in each scenario:
    ConditionActionUser Permission

    ViewAll = false,

    ModifyAll = false,

    Create = true

    Create

    The user can create a record.

    ViewAll = false,

    ModifyAll = false,

    Update = true

    Update

    The user can update records only if they own the record, or have edit access to a shared record.
    Note:

    The system throws a validation error if the user updates a record accessible through permissions other than owner scope (global/user/account).

    ViewAll = false,

    ModifyAll = false,

    Delete= true

    Delete

    The user can only delete records they own.

    Note:

    The system throws a validation error if the user deletes 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.

  7. Click Save Object Permissions.

To delete an object permission, select it from the list and click the Delete Object Permissions button.

Assigning Field Permissions

  1. Log in to the Conga Advantage Platform as an administrative user.
  2. Click the App Launcher () icon in the top left corner, then Admin Console > Users.
  3. Click the Permission Groups tab.
  4. Click the permission group name link from the list page, or click the More () icon adjacent to the record and click Edit.
  5. On the Object Permissions tab, find the object to modify and click the Set link in the Field Permissions column.
    This raises the ActivityHistory Fields pop-up.
  6. Apply Edit or Read Only to or deselect the fields you are modifying. All fields in an object have full read and edit access by default. This table outlines the access levels and 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.

    The 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.

    Note:

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

  7. Click Save.

Assigning Record-Type Permissions

  1. Log in to the Conga Advantage Platform as an administrative user.
  2. Click the App Launcher () icon in the top left corner, then Admin Console > Users.
  3. Click the Permission Groups tab.
  4. Click the permission group name link from the list page, or click the More () icon adjacent to the record and click Edit.
  5. On the Object Permissions tab, find the object you will modify and click the Set link in the Record Type column.
    Selecting a record-type object (Agreement, e.g.) raises a Set Record Type pop-up. Clicking objects that lack a record type results in an error.
  6. Assign access to the record field.
    By default, all record types are accessible to all users.
  7. Click Save.

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.

  1. Log in to the Conga Advantage Platform as an administrative user.
  2. Click the App Launcher () icon in the top left corner, then Admin Console > Users.
  3. Click the Permission Groups tab.
  4. Click the permission group name link from the list page, or click the More () icon adjacent to the record and click Edit.
  5. Open the Global Scope, User Scope, or Account Scope tab.
  6. 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.

  1. Log in to the Conga Advantage Platform as an administrative user.
  2. Click the App Launcher () icon in the top left corner, then Admin Console > Users.
  3. Click the Permission Groups tab.
  4. Click the permission group name link from the list page, or click the More () icon adjacent to the record and click Edit.
  5. Make required changes as described in Assigning Object Permissions, Assigning Field Permissions, Assigning Record-Type Permissions, or Adding Scope Permissions.
    Changes are automatically saved, and a confirmation message is displayed.

Deleting a Permission Group

  1. Log in to the Conga Advantage Platform as an administrative user.
  2. Click the App Launcher () icon in the top left corner, then Admin Console > Users.
  3. Click the Permission Groups tab.
  4. Click the More () icon at the start of the role record.
  5. Click Delete.
    A confirmation dialog appears.
  6. Click Confirm.
    Note:

    If the permission group is assigned to any user or role, you will receive a validation message and will be unable to delete the permission group.