This is for:System Administrator
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 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 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.
For example, in the Content service, one of the domains is Fields. If you grant a group the Edit access level on Fields, the members of this group will be able to change the configuration of the fields in your organization.
Some 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 (platform-ca | platform-eu | platform-au) 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. For example, when creating a new group, you could decide that its members can edit Source A, but only view Source B.
This feature works in a per-grantee fashion, i.e., on the Groups (platform-ca | platform-eu | platform-au) or API Keys (platform-ca | platform-eu | platform-au) page, you’ll select a group/API key, and then grant it View or Edit access on each resource. However, you also have the option to work in a per-resource fashion, which means you’ll select a resource, and then grant each group (and API key, if applicable) in your organization the privilege to view or edit it. This is done in the Access tab of the resource creation/edition panel.
Domains that offer the Custom access level and granular access levels include sources, groups, and API keys. See Privilege reference for details on the access levels available for each domain.
Your company uses Coveo to make its internal Atlassian content, its YouTube 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 YouTube source, and a Web source.
As a Coveo administrator, you can edit all sources. However, you want to delegate the responsibility to manage sources your company’s Atlassian administrator and marketing coordinator.
The Atlassian administrator should only be able to edit the Confluence Cloud and Jira Software Cloud sources, while the marketing coordinator should only be allowed to manage the 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 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 Enable1 The privilege to view an organization is required for a user to access the Coveo Administration Console. See Minimum Privilege for details.
Invite users in each group.
As a result, when the members of a group click a source on the Administration Console Sources (platform-ca | platform-eu | platform-au) page, the options available in the Action bar vary depending on their group’s access level for the selected source.
Members of the
Atlassian Administrators group, when clicking the Web source, only have the View option in the Action bar.
The non-Atlassian sources are also grayed out to indicate that due to their access level for these resources, the members of the
Atlassian Administrators group can’t edit their configuration.
Conversely, if they click the Jira Software Cloud source, which they have the privilege to edit, the Action bar offers an Edit button and content update options.
Later, if you want to make your Web source accessible to two more groups,
Coveo Administrator Intern and
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 checkboxes. See Navigate the Privileges Tab for details.
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. 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.