This documentation supports the 19.08 version of Remedy Action Request System.

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

Multitiered access control model

BMC Remedy AR System uses a multitiered approach to control data access. At each access level, a user's permissions are checked. If access is permitted, the user proceeds to the next level. If access is denied at any point except active links and active link guides (workflow), the user cannot proceed. (If access is denied at workflow, the user might be able to proceed, but his data access capabilities will be limited.)

For example, if a user is denied access to a form, the user cannot see any fields associated with the form. For another example, a user's ability to access a request depends on whether he belongs to a group that has access to the Request ID field.

Access control in BMC Remedy AR System

(Click the image to expand it.)

Access control levels

The access control model comprises the following levels:

Access level

Description

BMC Remedy AR System server

Users must pass an initial checkpoint when they start an BMC Remedy AR System client, such as a browser. At this point, users must enter a valid user name, a password, and, as an option, an authentication string. BMC Remedy AR System servers check the user name, password, and authentication string each time a client requests a transaction, such as when opening a form or changing a field. If your BMC Remedy AR System server is configured to allow guest users, such users can log in to the server without a valid user name or password. See User form access.

Form

As an administrator, you give groups access to forms according to each group's need to view or change information in the form. Visible access enables users to access a form from the Object List. Hidden access makes a form available only through workflow. Static permissions inheritance and dynamic permissions inheritance properties control access to the form for parent groups. If a group is not given access to a form, members of that group cannot view the form or change the requests that it contains.

Field

You can control access to each field on a form, including nondata fields such as trim fields, table fields, and active link control fields. You can make a field visible to users or hide the field so that it is accessible only through workflow. For data fields, you also specify whether a group can only view field information or also change it. If a group cannot access a field, the field does not appear when members of the group open the form.

Active link

In addition to controlling access to form and field data, you can control access to active links, which trigger a variety of workflow actions. For example, you might allow support staff to trigger several active links appropriate to their work but not allow other users to trigger those active links. Groups do not automatically have access to the field associated with an active link. You must grant them access to the active link and to the field. For active links that fire when users click a button or choose a menu item, the users must have access to both the button or menu item and the active link to trigger the active link.

Active link guide

When you create an active link guide, you specify the groups that have access to it. To access an active link guide, a user must have permission to each active link in the guide and to the guide itself. If a user has access to all active links in a guide but not to the guide, the guide does not appear.

Request

You can strictly control who can access requests associated with a form. For example, you might want only managers to access requests with confidential employee information. Or you might provide an outsourcing service in which you use BMC Remedy AR System as the central service desk for several companies, and you do not want one company to see requests from another company.

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

Comments