Manage privileges

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.

Important

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, that is, 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.

Example: Fields domain | Coveo

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.

Example: API Keys domain | Coveo

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.

Custom access levels | Coveo

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, that is, 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.

Access tab | Coveo

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.

Example

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:

  1. You create two groups, to which you grant the following access levels:

    Tip

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

  2. When selecting Custom for the Sources domain, you can select an access level for each resource in this domain. You therefore select View or Edit, depending on what each group should be allowed to do.

    Custom access levels | Coveo

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

The buttons in the Action bar change when selecting different sources | Coveo

Later, if you want to make your Web source accessible to two more groups, Coveo Administrator Intern and Website Developers:

  1. You select the Web source on the Sources (platform-ca | platform-eu | platform-au) page, and then click Edit in the Action bar.

  2. In the Access tab, you switch the access level of the desired groups to Edit.

  3. You click Save.

Edit access level for two new groups | Coveo

"Can create" ability dependence

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, the ability to create resources remains distinct from the Edit access level, which allows grantees to modify and delete resources. The Coveo Administration Console reflects this separation with dedicated Can create checkboxes. See the Navigate the Privileges tab page for details.

When you select the View all or the Custom access level for a domain that offers 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. As an example, in domains like Search pages and IPX, the Can create checkbox can be ticked without the need for the Edit 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.

Example

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.

Domain Access level
Analytics Viewers Limited Administrators John Smith
Administrate (None) Allowed Allowed
Data exports View Edit Edit
Dimensions View Edit Edit
Impersonate Allowed (None) Allowed
Named Filters View View View

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.