This documentation supports the 21.05 version of BMC Helix CMDB.

To view an earlier version, select the version from the Product version menu

Roles and permissions

You can assign users to groups and roles in the AR System server to control users' access to the application based on the tasks they need to perform. If you are creating custom groups and roles and not using the default groups created when installing AR System server, the overall process of providing access has the following basic steps:

The process does not include the first step if you are using groups and roles that were automatically created during installation. 

Related topics

Creating users, groups, and roles Open link

AR System: Regular, computed, and dynamic groups Open link

Access control overview Open link

Adding support staff in ITSM Open link

Providing users with permissions to access the CMDB Portal by using groups and roles

Creating normalization rules to set row-level permissions

Groups are permissions specific to a server while roles are used exclusively in applications. You must map a role to a group based on the level of access you wish to provide to that group.


A user is any person to whom you give permission to access BMC Helix CMDB. Users can be members of multiple groups or no group at all. Users in BMC Helix CMDB range from an administrator who maintains the entire system to employees who only view data.


Groups are collections of AR System users who are given access to perform specific tasks. Groups are specific to a server. A group has access to an object, a field, or a request, and any user added to that group inherits the same access. You can map a role to a group. You can also designate an entire group to be notified of a certain action. Installation of AR System automatically creates some default groups and you can also define additional custom groups.

AR System includes a public group and eight other special groups that are essential for access control within the system. You can define additional groups based on a common profile and assign access. For example, you might create a Sales group and allow members to view the status of a request but not to change it. A group can also be a general category, such as Browsers. 


Roles are permissions like groups, except that they belong to a particular application, instead of a particular server. Roles are used exclusively in deployable applications. Installation of applications such as BMC Helix ITSM automatically creates roles that you can later map to specific groups. You can also define roles when you need them.

You can map roles to different groups on different servers, depending on how the groups are defined on each server. This enables you to develop and test the application on one server and deploy it to many other servers without having to redefine permissions on each server. You can also map roles to different groups for each development state, such as testing or production.

Permissions model to provide access to the new CMDB Portal

Based on the groups users are assigned to, the features they can access varies. The AR System server groups referenced in this table are created automatically when you install CMDB and BMC Helix ITSM

Type of user and their requirementsAccess level in the new CMDB UIGroup to which you can assign the user


Requires all features of the CMDB Portal.

All areas of BMC Helix CMDB


CMDB configuration manager

Requires all features of the CMDB Portal except those which are related to Atrium Integrator.

Create jobs, edits jobs, creates rules, uses the dashboard, and so on.

All of the CMDB Portal except the following:

  • Cannot edit CIs.
  • Cannot create or edit classes.
  • Cannot access Atrium Integrator via the data flow diagram or Atrium Integrator job console.
RE Definition Author

CMDB data publisher

Performs asset related work, creates and edits CIs and other activities related to service modeling.

Requires access to Search and the CMDB Explorer in the CMDB Portal and also needs to be able to edit CIs in the CMDB Explorer.

  • Can access Search, CMDB Explorer, and can also edit all CIs in CMDB Explorer in the CMDB Portal.
  • Can access CMDB Explorer, CMDB Impact Simulator, and dataset configuration in the Atrium Core Console.

Important: An Asset Admin additionally requires RE Definition Author permission for unrestricted access to all CMDB pages in the Atrium Core Console and CMDB Portal.

Asset Admin

CMDB user

Perform asset related work.

Needs to only access the Search and the Explorer in the CMDB Portal. Does not need to edit CIs in the CMDB Explorer and cannot create or edit CIs.

Can access Search and CMDB Explorer. Can only edit non-asset CIs. Cannot edit CIs in the asset dataset or the golden dataset.

Task Manager, Task User, Task Viewer, Asset Viewer, Asset User, Asset Config, Infrastructure Change Master, Infrastructure Change User, Infrastructure Change Submit, Infrastructure Change Viewer, Infrastructure Change Config, Release Master, Release User, Release Viewer, Activity User, Activity Viewer, Release Config, Activity Config, Incident Master, Incident User, Incident Viewer, Incident Config, Problem Master, Problem User, or Problem Viewer


  • Users who have permissions to create and edit CIs must also have CI level permissions to be able to edit CIs.
  • Certain features may not be accessible to a user from the CMDB Portal because of the access level that the user has as mentioned in the preceding table. But, if the user has permissions to the AR System forms, the same features can be accessed by using the AR System APIs.

Normalization and instance permissions

You can use the Normalization Engine to set the row-level permissions for specified classes and, with AR System qualifications, specific instances.

To use the Normalization Engine for instance permissions, you must complete the following steps:

  1. Define the rules for setting the row-level permissions. (See Creating normalization rules to set row-level permissions.)
  2. For each data set, enable the Row-Level Security feature. (See Configuring normalization settings for datasets.)

In addition to the CMDB Data View and CMDB Data Change roles, users must also have row-level access to instances. Each class has two attributes that specify users with read and write access to the class instances.

  • CMDBRowLevelSecurity — Users who are members of a group with row-level access have permission to view the instance if they also have the CMDB Data View or CMDB Data Change role.
  • CMDBWriteSecurity — Users who are members of a group with write access have permission to modify the instance if they also have row-level access and the CMDB Data Viewer role. This permission gives a user write access to a specific instance without giving write access to all instances with one of the CMDB Data Change roles.

You can define groups for the following permissions:

  • View — Members of these groups and roles can view the attribute in the class form, but cannot modify its value.
  • Change — Members of these groups and roles can view and modify the attribute value.

Was this page helpful? Yes No Submitting... Thank you