Securing your application

When a user attempts to reference a form, field, active link, active link guide, or web service, the 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.

Granting permission to applications and their objects

You must grant or deny access to the deployable application itself, and to each form, field, and active link, and active link guide in the application. The objects in an application do not inherit the access you grant to the application itself. Likewise, if you deny access to an application, access is not denied to the objects within the application. 

You can configure default permissions for the application before creating the application object to simplify permissions assignment and ensure consistency within the application. See Defining-default-permissions. 

When you add a form to a deployable application, all explicit groups are removed from its permissions and from the permissions of its fields and all active links and active link guides that have the form as an associated form. If the application has default permissions, those are added. You can grant permissions to roles and implicit groups, as described in Assigning-groups-or-roles-access-to-objects, to these objects and fields as needed. (Default role permissions are not applied to forms in deployable applications. You must apply the role permissions to each form.)

When you remove a form from a deployable application, all roles are removed from the form's permissions, from the permissions of its fields, and from all active links and active link guides associated with the form.