This documentation supports the 21.3 version of BMC Helix ITSM.To view an earlier version, select the version from the Product version menu.

Permission groups hierarchy


Permissions groups are used to grant users access to applications, modules, and sub-components in BMC Helix ITSM.

There is a hierarchical relationship among the BMC Helix ITSM application permissions groups. The following table lists the permissions groups from greatest access level to the least access.


Permissions group

Access level

Example

Admin or Master

At the top of the hierarchy, grant users the highest level of access within a given application component. These permissions groups typically include the ability to create and modify all records within the component.

The Admin or Master permissions group access supersedes the User permissions group.

Incident Master

User

Grants users the standard level of access within a given application component. This permissions group typically includes the ability to create and modify records. There are, however, some limitations imposed when modifying records.

The User permissions group access supersedes the Submitter permissions group.

Asset User

Submitter

Grants users the permission to create records, but not to modify them.

The Submitter permissions group access supersedes the Viewer permissions group.

Change Submitter

Viewer

Grants users read access within a given application component.

Problem Viewer

Important

Config is also a permission group, but it falls outside the hierarchy of the above permissions groups. The Config permission group grants access to configure an application. An example of Config permissions is Incident Config.

Each higher-level permissions group grants all of the access rights of the permissions groups below it in the hierarchy. For example, if you assign someone to the Change Master permissions group, you do not need to assign them to the Change User permissions group. As a member of the Master permissions group, they automatically have User permissions, and so on.

If you assign a user to more than one permissions group for the same application component, you create a variance in the recommended permission combinations.

  • When you assign a user to more than one permission group for the same application, the user is granted the permissions associated with the permission group with the greater access. For example, if a user is added to the Master permission group and the Viewer permission group, the user has Master permissions.
  • In some cases, the functions from one permissions group are automatically granted to another permissions group. For example, if you grant someone Incident User permissions, you do not have to grant them Task User permissions. Incident User permissions automatically inherit the functions of the Task User permissions.