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.

Access control for a deployable application

You use only roles and implicit groups to grant permission to objects in a deployable application. Because you map each role to an explicit group and the BMC Remedy AR System server uses the role mappings to determine access, the groups on servers where the application is deployed do not need to be the same as those on the development server.

The server also uses the application state to determine the group currently mapped to a role. By mapping different groups to a role for different states, you control access to the application based on it's current state. For example, when the application is in the Test state, only users in the mapped testing group can access the application. When you change the application state to Production, users in the group mapped to the role for the Production state gain access. For more information, see Working with deployable application states.

When a user attempts to reference a form, field, active link, active link guide, or web service, the BMC Remedy AR System server uses the application state and the role mappings of the controlling application to determine access. When a form is in a deployable application, that application controls the form. The application also controls the fields in the form, and any active links, active link guides, and web services for which the form is the primary form.

When working with a deployable application, keep the following points in mind about the controlling application:

  • If a form or active link guide is an entry point, it appears under its controlling application on the home page. A user who does not have access to an application has limited access to the application's entry points. See Creating and managing fields.
  • If an active link or active link guide in a deployable application is shared outside of its controlling application, access to the active link or active link guide is determined by the role mappings and state of the controlling application. In this case the developer must coordinate the roles of the controlling application with those of the integrated application to ensure that the workflow is accessible and operates as expected.
  • If you delete the primary form of an active link or active link guide, one of the other associated forms becomes the primary form. If the new primary form is in a different deployable application, the controlling application of the workflow object changes, and the role permissions are those of the new controlling application.
  • Flashboards and flashboard variables function as global objects. They can be in a deployable application, but they are not controlled by the application. You must grant permissions to these objects using groups and not roles.
Was this page helpful? Yes No Submitting... Thank you