In a Coveo organization, few people need to access all features of the Administration Console. Depending on how responsibilities are delegated, some organization members may only need to access a couple pages of the Administration Console to accomplish their tasks. Similarly, the Coveo Cloud API keys you create may only need to have access to a specific part of your organization to allow their holder to serve its purpose.
In this regard, a privilege determines what its grantee can do with a subset of features or data of a Coveo organization. The grantee can either be an API key or a group of organization members. When granted privileges, a grantee can be allowed to view, edit, and/or create resources, perform actions, etc. to accomplish their tasks relatively to your Coveo organization.
To manage the privileges of a group or API key in the Coveo Administration Console, one must have the privileges to edit this group or API key. To create a new group or API key and grant it privileges, the privilege to create resources of the desired type is required.
The operation of granting privileges isn’t to be taken lightly, as insufficient privileges can hinder task accomplishment, while inadequate or unnecessary privileges could lead to accidents or misuse. When allowed to delegate powers, you should have a good understanding of how the Coveo Cloud privilege system works and be aware of the implications of each choice you make.
In this regard, we recommend reading the privilege documentation before granting privileges or editing a privilege set. Enforcing the principle of least privilege, i.e., granting just enough privileges for the grantee to perform their task, is also strongly encouraged.
Services, Domains, and Access Levels
Your Coveo organization consists of several domains grouped in services. Each domain represents a page of the Coveo Administration Console, a type of resource, or a set of data. Related domains are assembled in a service.
When a group or an API key is granted a privilege, it’s granted a certain level of access with regard to a domain. Therefore, privileges represent an access level applied to a certain subset of features or data.
Most domains offer the following access level options:
View: the grantee can access the domain, but can’t edit it.
Edit: the grantee can access the domain and change its parameters or the configuration of its resources. This access level also allows the grantee to delete resources.
Some of these domains offer the Custom access level, which allows granting privileges granularly, resource by resource. Most domains also offer the Can Create ability, which allows the grantee to create new resources.
Typically, the domains that offer the View and Edit access levels are related to a page of the Administration Console. For example, the Sources domain is associated with the Sources page, and the Can Create ability on the Sources domain allows its grantee to create sources.
Some other domains, however, rather represent an action that can be performed in your organization, and don’t relate as closely to an Administration Console page. With these domains, you can grant the Allowed access level to allow the grantee to perform the action. When granted the Allowed access level for the Delete User Data domain of the Analytics service, for example, an organization member can permanently delete user data, which can affect usage analytics dashboards and reports.
Custom Access Level
With some domains, you can select the granular Custom access level as an alternative to the View all and Edit all options. When you do so, a list of the resources in this domain appears, and you can select access levels in a granular fashion, resource by resource. For example, in the Sources domain, each source in your organization is a resource.
In other words, the Custom access level allows you to decide whether an API key or the members of a group can view or edit each resource individually. So, by selecting View for some resources and Edit for some others, you grant a group or an API key the privilege to modify only certain resources in a domain. For example, you could grant members of a group the Edit access level for resources 1 and 2, but only the View access level for resources 3, 4, and 5.
Domains that offer the Custom access level and granular access levels are:
Your company uses Coveo Cloud to make its internal Atlassian content, its social media content, and its website content searchable by its employees. In your Coveo Administration Console, on the Sources page, there’s therefore a Confluence Cloud source, a Jira Software Cloud source, a Twitter source, a YouTube source, and a Web source.
As a Coveo Cloud administrator, you can edit all sources. However, you want to delegate the responsibility to manage sources to other people, i.e., your Atlassian administrator and your marketing coordinator.
Your Atlassian administrator should only be able to edit Confluence Cloud and Jira Software Cloud sources, and your marketing coordinator should only be allowed to manage Twitter, YouTube, and Web sources. Moreover, both should be able to use source-related content management features, and they shouldn’t have access to other Coveo Cloud functionalities, such as usage analytics.
In sum, the two groups are nearly identical, the difference being the sources for which they’re responsible.
The implementation of this segregation of duties goes as follows:
You create two groups, to which you grant the following access levels:
To save time, instead of creating two new groups from scratch, you can create one, grant them the desired privileges, and then duplicate it. Next, you edit the duplicate group to grant it the desired granular access level for the Sources domain.
Service Privilege Access level Content Extensions Edit all Fields Edit Sources Custom (see Step 2) Organization Activities View Organization View1 Search Execute Queries Enable
1: The privilege to view an organization is required for a user to access the Coveo Administration Console (see Minimum Privilege).
Invite users in each group.
As a result, when the members of a group click a source on the Administration Console Sources page, the options available in the Action bar vary depending on their group’s access level for the selected source. Members of the
Marketing Coordinator group, when clicking an Atlassian source, only have the View option in the Action bar. The Atlassian sources are also grayed out to indicate that due to their access level for these resources, the members of the
Marketing Coordinator group can’t edit their configuration.
Conversely, if they click the Twitter source, which they have the privilege to edit, the Action bar offers an Edit button and content update options.
Can Create Ability Dependence
The ability to create resources is distinct from the Edit access level, which allows grantees to modify and delete resources.
The Coveo Administration Console also reflects this separation with dedicated Can Create check boxes (see Navigate the Privileges Tab).
In most domains, the ability to create resources is dependent on the selected access level. So, groups or API keys granted the Edit access level on a domain are also automatically granted the ability to create resources in the domain, while those granted the View access level aren’t granted this additional ability. You therefore have no decision to make in this regard.
However, when you select the View all or the Custom access level for a domain that offer these options, you must decide whether the grantee should also be able to create new resources in this domain. In the Administration Console, you can check the box to grant this ability in addition to the selected access level.
Conflicting Access Levels
An access level conflict happens when an organization member is part of groups that have been granted different access levels for a domain.
In such a situation, the highest access level granted for each domain is enforced for that member.
For each domain, access level conflicts are solved as follows:
The Edit and Allowed access levels and the Can Create ability are enforced if at least one of the conflicting groups grants them.
If none of the conflicting groups grant the Edit access level, but at least one of them grants the View access level, View is enforced.
John Smith is a member of the Analytics Viewers built-in group, as well as the custom Limited Administrators group (see Create a New Group). The following table shows some privileges of the Analytics service granted to both groups and the resulting privileges granted to John Smith.
|Analytics Viewers||Limited Administrators||John Smith|
John Smith can therefore, as a member of the group Limited Administrators, edit dimensions, and, as a member of the Analytics Viewers, he can also use the user impersonation feature. As for the Named Filters domain, there’s no conflict, since both groups are granted the View access level.