Skip to main content



Coupa Success Portal

Permissions Scheme


The permissions scheme is actually split into 5 areas:

  1. Access to Contract documents

Access to contracts documents are segregated by ‘Sites’. The contract “folders” are created in sites and by giving users access to a site, they inherently obtain access to the subfolders (i.e. the transaction folders and actual documents therein).

There are 4 access levels:

  • Manager (akin to Administrator access)
  • Collaborator (i.e. read, create and edit own & others’ contracts)
  • Contributor (i.e. read, create, and edit own contracts only)
  • Consumer (i.e. read only)

Whenever access is specified, the level of access needs to be specified as well. (The access level is maintained for all child objects).

It is possible to break the inheritance of permissions to child objects, however at this point those objects need to be maintained manually. As such it is not recommended.

More recently, contract level permissions have been developed as this is a common requirement for clients. This enables the users/groups and levels to be set during the Template Interview. Afterwards it is possible to maintain the permissions using the same method as for a contract where permission inheritance has been broken. However, the additional template logic will need handling when a user revisits the interview. Furthermore, as the Template answerdata is stored separately from the CLMA data, once permissions are changed through the UI, the data will be out of sync. As such, this approach is also not recommended.

  1. Permissions to which contracts a user can create

To create a contract, a user needs to run a Smart Template that takes the user through an ‘interview’ (that collects the data and generates the document). These templates are configured in the Template Bank of the application, where one of the items configured is the list of user groups who has access to run the template. Refer to Template Configuration for more details.

(In order to access the Templates, the user needs to have Contributor or higher access on that site).

  1. Action configuration (i.e. what actions can be performed under which circumstances)

When navigating to a contract, there is a number of actions that a user can perform based on:

  • Their usergroup membership
  • The status of the contract
  • The template used to create the contract
  • The content type (when viewing documents/folders other than contract documents)

These actions are defined in the ‘Action Configuration’. Although it is possible to configure these per site, the recommended approach is to configure it at a global level.

An example of an “Action Configuration Rule” is as follows:

Use the default configuration (which use the default roles) as your starting point and only modify in line with the business process and role design.

For a full list of available actions, please refer to .

Please note that some actions are dependent on other settings or are hard coded. An example is that even if you configure the ‘Create Amendment’ action to be available, it will only show if ‘Allow Create Amendment Interview’ has also been selected for that particular contract template.

A list of exceptions can be found at

  1. Access to certain features

Certain features are locked behind user group membership. In order to gain access to that feature, the user needs to be in that user group. Generally speaking, these are features (e.g. Entity Manager) which appear on the sub-menu bar:

If a parent user group is nested in the “feature user group”, all users in the child user groups will also have access to the feature, with one notable exception:

There is currently a known issue related to obtaining access to the ‘Alfresco Processing Services’ (APS) console.

APS is the workflow engine. It is a separate application, tightly integrated, and as such has its own user accounts. The user accounts are automatically created for users (via an automated sync that takes place every 20 minutes), added to either the “Activity_managers” or “Activity_manager_initiators” user groups. Unfortunately the integration only creates accounts for users in the “root” level of this user group, and does not take into account users in nested user groups. (As CLMA will move to use the workflow engine in the Core application, a fix is not expected for this issue.)


  1. Administrator related features and privileges

 Similar to certain features being locked behind user group membership, to access Administrator features the user needs to belong to the “CLMA Admin” group. This membership however gives more access than just access to the ‘Repository’ and ‘Admin Tools’ features on the sub-menu bar. It also automatically gives users read/write access to all content. (It is still possible to hide certain actions using Action Configuration from an Administrator’s view, however the Administrator can simply update the Action configuration if they wish to give themselves permission.)

Scoping Questions

  • What roles are involved in the full lifecycle of a contract, including approvals and amendments/renewals?
  • Does everyone with access to contracts have the ability to amend (which in draft)? Are there some groups who need Read only access e.g. approvers, auditors? Please give details.
  • How are contract access currently segregated?
  • Are there any restrictions where users may not have access to contracts e.g. US resources not able to access contracts that are not related to a US legal entity, etc.

Design Options

The requirements ultimately drive the design, however from a best practices perspective, aim to get as close to:

  • Contract permissions managed at site level
  • User roles defined by user group and constant across sites
  • Design user groups to nest as follows: licence type > role > further segregation by contract accessibility (this will be informed by your site structure design. e.g. countries > branches, etc.)
  • Action configuration consistent across sites
  • Actions available limited to only what is needed. Don’t leave extra features available as this only invites confusion / feature bloat (e.g. having both check out/in as well as download/upload new version)


Due to the various permission areas and that they overlap, the permissions scheme can get very complicated very quickly. As an overall guiding principle - the simpler the better. Just because the system can, doesn’t mean you should.

Things to avoid

Avoid implementing a contract level permission scheme (if at all possible). Maintaining individual permissions is not intuitive nor user friendly. Additionally, it is not possible to easily see which contracts’ permissions are being maintained individually from others, so maintenance thereof is challenging.

  • Was this article helpful?