This page describes the different security options for the record type, record views, and related actions. For more information on object security, see Object Security.
The security role map of a record type controls which users can see or modify it and its properties. By default, only the record type creator and system administrators have access to the record type. See Editing Object Security to modify a record type's security.
The following table outlines the actions that can be performed by each permission level in a record type's security role map:
|View record type in Tempo||Yes||Yes||Yes|
|View record type definition||Yes||Yes||Yes|
|View the security||Yes||Yes||Yes|
|Update record type definition||Yes||Yes||No|
|Update the security||Yes||No||No|
|Delete the record type||Yes||No||No|
Preventing users from being able to view a record type does not secure the record type's underlying data source. Users may still be able to view the underlying data in other areas of Appian.
Individual record security is based on the security of the underlying source. Users must have at least Viewer permissions to the record's source to view the record in the record list or to view its record views.
For example, applying a default filter to hide a specific group of processes will stop those records from generating, but the process data might still be visible in a process report or process dashboard.
The security of the record's source is configured differently for the different source types.
For record types with a database table as the data source, see Security and Record Level Security for Entity Backed Records.
For record types with a process model as the data source, see Configuring Process Security.
For record types with a web service as the data source, both the list view and record view source expressions execute in the context of the user viewing the record list. Even if these source expressions are defined using rules, the security role map applied to those rules does not prevent any users from executing the rule by viewing the record list.
Access to the underlying data must be controlled by the developer of the rule in its definition in conjunction with the access control mechanisms available from the provider of the data. For instance, if the rule retrieves data from an external data provider that requires credentials for authentication and authorization, the rule developer must build the retrieval and presentation of those credentials into the definition of the rule.
For more information, see Expression Rule Security.
Security for record views is a combination of the source security, record type security, and default filter configurations.
A user must be able to view a record in the record list to access the record. Anyone with access to the record will see the Summary view by default. If a user does not have access because of source security, record type security, or a default filter configuration, the user cannot access the record views even if given a direct URL.
Each additional record view also has its own security. This is based on the visibility expression defined for the view. Users may access additional record views by navigating in Tempo or by using a record link that is configured to go to a certain view. Record links respect record view visibility.
Hiding data on a view does not secure the underlying data. It only determines what does not display on the view.
Security for starting related actions is based on the security of the underlying process model. Users can only start a related action if they can view the record and have Initiator permissions to the process model for the action. The same applies for quick tasks that appear as related actions for record types that use a process model as their source. If the user does not have the permissions to complete the quick task, the link to the related action will not display under Related Actions.
On This Page