Bloomreach Engagement has developed Role-based access control to protect your data from unauthorized access. Having the access minimization principle in mind, this system allows you to make sure that only the right people have access to personal data or specific modules.

With Bloomreach Engagement, you can define and manage dedicated persons with specific permissions, such as modifying, viewing, or exporting customer data and executing campaigns. You can set separate access with the explicit purpose for each user either on a project or account level.

To do this, go to `Settings > Project settings > Access management` where you can select from, assign, and modify specific access rights.

Project limit

Note that in each project there is a limit of 1000 users.

# Role-based access control (RBAC)

Role-based access control groups small sets of specific permissions and accesses under "roles" that can be assigned to team members by the Admin. This way, administrators can decrease the risk of major mistakes and security breaches by carefully restricting users' access to perform only the tasks they really need.

## Inviting a new project member

You can invite new users to your project and decide which role suits their work. They will have to accept your invitation, and until they do so, they will appear within pending invitations.

The **invitation is valid for seven days** for security reasons. After this time, the invited user will no longer be able to accept it, and the Administrator or Super Admin has to resend the invitation.

You can make changes to the specific role and permissions while the invitation is pending, and you can further refine user accesses even after the invitation has been accepted. Thus, do not worry if you accidentally invite someone with an incorrect role or permissions, as the Project Administrator can change the role anytime.



## Configuring permissions

Once the user is in the project, you can adjust their project role by hovering over their name and clicking on the `Edit` button on the right side in the `Project team` tab. Here, you can select multiple roles from a list of roles (some of which are described in the table below). Bloomreach Engagement predefines several roles, and you can also **create your own custom roles** to suit your specific needs.



### Assigning multiple roles

You can assign multiple roles to each user by scrolling down their individual access permission setup and selecting `Add role group`. Then, in `Project team` you can see all individual roles and their descriptions under that person's name.



### Temporary roles

The administrator can grant the user a temporary role by setting an expiration date in the user interface. Select the icon `Add expiration` and select the exact day and time that the user's role will expire. Expired roles are visible in the interface but are not active and do not grant any permissions. We recommend setting expiration for highly sensitive roles, such as Admin roles and Personal Data Viewer.



# Permission hierarchy

## Roles naming hierarchy

There are several access roles in Bloomreach Engagement out of the box. To make it easy for you to quickly understand the scope of the role, all of them abide by the following naming convention: **The first word or two represents the section of the application, and the later the extent of the permission**.

Regarding the extent of the permission, there are **levels of roles** with an increasing set of permissions, creating a hierarchy of roles, as described in the flowchart below. **Higher-level roles inherit all permissions from the lower ones, and lower levels never allow functions from higher-level roles.** For example, while an Admin has access to all other functions, sole Editors cannot publish or export from Bloomreach Engagement (they can only do the task they are assigned and abilities hierarchically beneath them). All standalone roles follow this hierarchy and naming.

2000


**Admin**: has full access to Campaigns (can view, edit, delete, start, and stop all Campaigns; can edit running Campaigns; can change Campaigns settings); can edit customer data excluding customer consents; can edit consent settings **Editor**: can write and delete access; can modify and delete objects. **Publisher**: can execute access; can trigger an action that may immediately impact the end customers or make objects publicly available. **Exporter**: can export or download data from the Bloomreach Engagement application. **Approver**: can only approve specific actions. **Requester**: can create a request. **Viewer**: read-only access; cannot modify objects.

Example of permissions hierarchy

The lowest-level role, the **viewer**, has their set of defined permissions.

The higher-level role, the **editor**, has their own set of permissions **AND** those of the **viewer**.

And the **publisher** has their set of permissions **AND** those of the **editor**, which also **include** those of the **viewer**.



## Permission scopes hierarchy

**Be aware of the hierarchy between Instances, Accounts, and Projects**. Roles granted on a higher scope (account) are applied to all lower scopes (project). Similarly, if users operate on their own single-tenant instance, that instance has the highest hierarchy (instance -> account -> project)

For example, if a user is granted "Analyses Viewer" on the Account scope, the user will have the "Analyses Viewer" role in all projects under that account.

Roles assigned to users on an instance scope are applied to all accounts and projects within the instance. Roles assigned to users on account scope are applied to all projects within the account.

2000


Ensure Project Safety by granting a role on the correct Scope

Roles assigned to users on an instance scope are applied to all accounts and projects within the instance. Roles assigned to users on account scope are applied to all projects within the account.

This might be critical, as you might be granting Account rights to someone, who is supposed to see or edit one Project ONLY.

# Roles

## Predefined roles

Several predefined standalone and non-standalone roles come out of the box and can be assigned to the members/users of your project. All standalone roles follow the naming and hierarchy of roles described above.

In addition, there are several non-standalone roles set up by Bloomreach Engagement that allow access to specific actions.

Remember

A user can have **multiple roles assigned**, but each user must have **at least one standalone role **to be able to access the project.

The following is the list of all predefined roles in Bloomreach Engagement.

Role typeDescriptionStandalone
Account AdminHas full access to accounts, projects, and customer data within an account; has full access to account access management; has full access to account-specific settings; can edit group access.Yes
Account IAM AdminThe role allows the administration of Identity and Access Management (Roles, Policies, and Service Accounts) on the Account and Project levels.No
Account Temporary Access ApproverCan approve temporary access requests on the Account and Project levels.No
_Account User (Legacy)_Can open account; can view account overview dashboards.Yes
Analyses EditorCan view, edit, and delete all [analyses](🔗) (dashboards, reports, segmentations...); can edit customer data - excluding consents; can share dashboards.Yes
Analyses ExporterCan view and export all analyses; can share dashboards.Yes
Analyses ViewerCan view all analyses.Yes
SSO Account AdminHas full access to accounts and can log in using the backup magic login link method.Yes
Campaigns AdminHas full access to Campaigns (can view, edit, delete, start, and stop all Campaigns; can edit running Campaigns; can change Campaigns settings); can edit customer data - excluding customer consents; can edit consent settingsYes
Campaigns EditorCan view, edit, and delete Campaigns; can edit customer data - excluding consents; can view, edit, and delete Catalogs.Yes
Campaigns ViewerCan view Campaigns and their evaluations.Yes
Customer Data ExporterCan export customer data in bulk (download).Yes
Email Campaigns EditorCan view, edit and delete Email Campaigns; can view Catalogs.Yes
Email Campaigns PublisherCan view, edit, delete, and publish Email Campaigns; can view Catalogs.Yes
Email Campaigns ViewerCan view Email Campaigns and their evaluations; can view Catalogs.Yes
Experiments EditorCan view, edit and delete Experiments.Yes
Experiments PublisherCan view, edit, delete, and publish Experiments.Yes
Experiments ViewerCan view Experiments and their evaluations.Yes
Exports Module AdminHas full access to set up Exports of customer data, including PII.Yes
Personal Data Viewer (flag)Has view access to private fields (personal data, PII).**No**
Project AdminHas full access to everything in projects; has full access to the project access management; can edit customer data - including consents.Yes
Project IAM AdminThe role allows the administration of Identity and Access Management (Roles, Policies, and Service Accounts) on the Project level.No
Project DeveloperHas full access to imports, catalogs, integrations (including approval); can change selected project settings; can view customer data.Yes
Project Temporary Access ApproverCan approve temporary access requests on the Account level.No
_Project User (Legacy)_Can open projects and view customer data.Yes
Recommendation EditorCan view Segmentations and view, edit, and delete Recommendations; can view Catalogs.Yes
Recommendation ViewerCan view Recommendations and Segmentations; can view Catalogs.Yes
SMS Campaigns EditorCan view, edit and delete SMS Campaigns; can view Catalogs.Yes
SMS Campaigns PublisherCan view, edit, delete, and publish SMS Campaigns; can view Catalogs.Yes
SMS Campaigns ViewerCan view SMS Campaigns and their evaluations; can view Catalogs.Yes
Technical SupportHas roles: Analyses Editor and Analyses Exporter, Campaigns Admin, and Customer Data ExporterYes
Temporary Access ApproverCan approve temporary access requests.No
Weblayers EditorCan view, edit and delete Weblayers.Yes
Weblayers PublisherCan view, edit, delete, and publish Weblayers.Yes
Weblayers ViewerCan view Weblayers and their evaluations.Yes

The special role of "Personal Data Viewer" grants access to private fields (personal data, PII). Bloomreach Engagement predefined roles never include this role. Personal Data Viewer must be granted **explicitly** or included in your custom roles.

To read more about the roles and see which specific roles are inherited, find the role in `Access management > Roles`.

Standalone role required

Remember that each user must have **at least one standalone role** to be able to access the project. If a user does not have any standalone role, for example, only being a `Personal Data Viewer`, they will have a problem with logging into the project.

### Instance-level roles

Bloomreach Engagement offers three main types of instances for your projects: multi-tenant, single-tenant, and exclusive instance. These contain different features and configurations of data layers. In each instance, data is separated, and access management is enabled to ensure your security. You can learn more about our [Security architecture](🔗) in its separate article.

What is important for Access management is that the additional layers of security within the more sophisticated types of instances, such as the single tenant or exclusive instance, will require some additional roles and accesses or permissions compared to the multi-tenant instance. There are these additional roles for projects running on a single tenant instance, as described in the table below.

RoleDescriptionStandalone
Super AdminHas full access to all accounts _(Account Admin)_, projects _(Project Admin)_ and customer data (including PII); has full access to instance-specific settings; has full access to the instance access management; can see and edit CDN setting field.Yes
Instance ManagerHas full access to all accounts _(Account Admin)_, projects _(Project Admin)_, and customer data (including PII); has full access to instance-specific settings; can see and edit CDN setting field.Yes
Temporary Access RequesterCan request temporary access.No
_Sales (Legacy)__Will be added shortly_No
AccessLockedProjects (flag)_Will be added shortly_No
DebugImf (flag)_Will be added shortly_No
OverrideSqlAccess (flag)_Will be added shortly_No
ListAllProjects (flag)_Will be added shortly_No

### Granular roles

Bloomreach Engagement allows you to assign finely detailed roles to your project members, not limiting you to choose from broader predefined roles listed above. Remember, a user can have multiple roles assigned, but each user must have **at least one standalone role** to be able to access the project.

RoleDescriptionStandalone
Account Usage ViewerCan view the Usage Dashboard on the Project and the Account level.Yes
Customers ViewerCan view Customer attributes and events; can view Catalogs.Yes
Customers Consent EditorCan grant and revoke customer Consents; can view Customer attributes and events.Yes
Customers EditorCan view, edit and delete Customer attributes and events; can view Catalogs.Yes
Data Manager ViewerCan view Data Manager.Yes
Data Manager Definition EditorCan view, edit and delete Data manager definitions.Yes
Event Analyses EditorCan view, edit and delete Event Analyses (e.g., Funnels, Trends, Retentions, Flows, and Geo Analyses).Yes
Event Analyses ExporterCan view, edit, delete, and export Event Analyses (e.g., Funnels, Trends, Retentions, Flows, and Geo Analyses).Yes
Event Analyses ViewerCan view Event Analyses (e.g., Funnels, Trends, Retentions, Flows, and Geo Analyses) and their results.Yes
Imports AdminCan view, edit and delete Imports and Catalogs.Yes
In-App-Message EditorCan view, edit and delete In-App-Message.Yes
In-App-Message PublisherCan view, edit, delete, and publish In-App-Message.Yes
In-App-Message ViewerCan view In-App-Message and their evaluations.Yes
Initiatives EditorCan view, edit and delete Initiatives.Yes
Integrations EditorCan view, edit and delete Integrations; can create already approved integration types (accepted Terms & Conditions).Yes
Managed Endpoints EditorCan view and edit Managed Endpoints; can view Catalogs.Yes
Managed Endpoints PublisherCan view, edit and publish Managed Endpoints; can view Catalogs.Yes
Managed Endpoints ViewerCan view Managed Endpoints and their evaluations; can view Catalogs.Yes
Project Usage ViewerCan view the Usage Dashboard on the Project level.Yes
Reports EditorCan view, edit and delete Reports.Yes
Reports ExporterCan view, edit, delete, and export Reports.Yes
Reports ViewerCan view Reports and their results.Yes
Scenarios EditorCan view, edit and delete Scenarios; can view Catalogs.Yes
Scenarios PublisherCan view, edit, delete, and publish Scenarios; can view Catalogs.Yes
Scenarios ViewerCan view Scenarios and their evaluations; can view Catalogs.Yes
Segmentations EditorCan view, edit and delete Segmentations.Yes
Segmentations ExporterCan view, edit, delete, and export Segmentations.Yes
Segmentations ViewerCan view Segmentations.Yes
Surveys EditorCan view, edit and delete Surveys.Yes
Surveys PublisherCan view, edit, delete, and publish Surveys.Yes
Surveys ViewerCan view Surveys and their evaluations.Yes

## Custom role

While Bloomreach Engagement predefines roles, **you can set up your own custom roles**. This allows you to add and combine several inherited roles to create a single role that would suit your specific needs. In other words, custom roles are stacked from predefined roles and inherit all their permissions and scope level.

To do so, go into the`Project settings > Access Management > Roles` and click on `+ Create custom role` in the top right corner. Select `+ Add inherited role`.



When there is a team with the same responsibilities and permissions operating the Bloomreach Engagement application, we do recommend creating a custom role. This custom role would inherit all required roles - allowing you to then only assign this single role to all team members. Furthermore, this makes it easier to see who is currently a member of this role on the Custom role`Members` tab.

Limitations

Custom roles (user-defined) can be combined from multiple roles, but it is not possible to remove a permission from a particular role.

There can be a maximum of 100 custom roles.

One custom role can include maximum 32 roles.

Remove access for users

Removing a user only removes their access. However, all analyses and campaigns they created will remain.

Assign users to access groups

In case you want to add more security and refine further what exactly specific users with their roles can edit within Bloomreach Engagement, you can **assign users to access groups**. Learn more about **User Groups Management** in our [documentation](🔗).

# Identity domain

Under `Access Management > Account team/Project team`, you can check who is part of your identity domain.

The identity domain serves to solve the tension between users having only _one user account_ but _access to multiple accounts_ and projects. It is unclear what policies to follow when enforcing some requirements (such as requiring an email and password or SSO to log in). During the login process, it is unclear what accounts would be accessed since users have access to multiple, and these have different settings.

However, the identity domain solves this issue. When users are invited to the instance for the first time, an account is set up where they were invited as their native domain. Following this, the policies and settings from this account would apply to the user.

Currently, the identity domain supports the following settings:

  1. [Single Sign-on ](🔗)

  2. Authentication methods

  3. [Password settings](🔗)

You can check who is part of your identity domain under `Access Management > Account team/Project team`.

There is a column called **Native account**. If the name matches the account name, the user belongs to this account, and the settings apply. If there is "Other", the user is from a different account. We do not reveal the native account of the users to other clients to avoid revealing what other accounts are on the instance.

If you need to change the native account for your user, please get in touch with our support team.



# Troubleshooting

## error "Forbidden 403":

When user roles are changed, there is a slight delay before the new permissions are applied. Be aware that permission changes are not applied immediately – it may take up to one minute to propagate changes into all components. If you are still getting the error after waiting a few minutes and reloading the application and think you should have access or permissions for this action, please contact our support.