Permissions are a crucial aspect of managing access control within Constructor, ensuring that users only have access to the specific data, features, or actions relevant to their role.

In Constructor, admins assign roles to users. These roles determine the type of access a user has to an index and the products and features within those indexes. There are two types of access: edit and view. By default, all roles have view permissions across all indexes, products, and features. Admins must explicitly grant edit permissions by first choosing the desired index and then selecting specific products and features within that index.

For example, the below user can take action for Searchandising Rules(e.g., create rules, edit rules, delete rules, etc.) and Recommendations (e.g., create pods, edit pods, create rules for pods, etc.) for one index: Germany. For all other indexes and features, the user can view information but not take action.

Default roles in Constructor

All companies using Constructor have two default roles that cannot be deleted:

• Default user role
  • Default users have edit permissions for all products and features in all indexes within a company’s account. This means users with this role can create, edit, and delete rules, configurations, and content. These users can also update index names and the item image base URL.
  • Users with this role cannot manage users (e.g., create, edit, or delete users), copy configurations and rules across indexes, manage searchabilities and facet configurations, generate and manage API tokens, and delete recommendation pods with history.
• Admin
  • Admin users have the highest level of permissions. Users with this role have access to all indexes within a company’s account and the ability to create, edit, and delete rules, content, and settings for all products and features within those indexes.
  • Admin users can also create new users and edit the permissions of existing users.

ℹ️

A note about view access

All roles in Constructor will, by default, have view permissions. Even if a role cannot edit or perform actions for specific products or features, users can still view that information. This is also true for the main Constructor dashboard, which provides an overview of performance information. There is no way to restrict what parts of the dashboard (or which indexes) a user can view.

How do we know if we need additional roles?

Admin users can create additional user roles and assign those roles to users if the company (or admins) wish to have more granular control over which users have edit permissions for specific products or features in specific indexes.

Learn how to create a new user role here.

Please note: Similar to the default user role, any newly created user role will have complete view permissions for the Constructor dashboard, including all indexes.

Example roles by product and feature access

• Assign product and feature access based on job duties.
  • For example, a company has a team of merchandisers who are in charge of managing searchandising rules across multiple indexes to maintain consistency in promotions.
  • The company could create a "Merchandisers" role and assign edit permissions for Searchandising Rules in each index where the team needs access. Once created, the admins can assign that role to merchandising team members.

Example roles by index access

• Assign index access based on location.
  • For example, a company has several geo-specific indexes (e.g., North America, United Kingdom, France, etc.). Members of their North America team do not need edit permissions for the other indexes. The company could create a "North America Team" role that only grants edit permissions for the North America index.
  • For example, a company has a team of developers who use a development or testing index. The company could create a "Developer" role that only grants edit permissions for the development index.

Example roles with a combination of index and product/feature access

• Assign index access based on job duties.
  • For example, a company is onboarding two new employees who will assist with creating collections, searchandising rules, and recommendation pods. Admins want to grant access to a testing environment where these employees can practice these actions before being allowed to perform tasks in the production index.
  • The company could create a "New Employee Merchandising" role that only grants edit permissions for Collections, Searchandising Rules, and Recommendations in the testing index.
  • Bonus? These employees would still be able to view collections, rules, and recommendation pods in the production index.