Object security is an integral part of application development, and critical for ensuring that the right users and developers have the appropriate permissions within an application. This page covers the fundamental concepts and behaviors related to object security in Appian, and provides best practices and guidance on how to ensure your applications are secure.
Groups, role maps, security inheritance, layered security, and object visibility are important concepts to learn in order to fully understand object security.
Object security is made up of two tightly coupled concepts: groups and role maps.
Role maps are mappings between a series of groups or users and their permissions to an object. Each object in Appian has just one role map. To set an object’s security, simply edit its role map.
Appian recommends using only groups to set object security. This allows you to control object access by changing a user's group membership, rather than directly editing the object’s role map.
The following image shows an example process model role map. Notice that ABC All Admins have Administrator permissions to this process model while ABC All Viewers only have Viewer rights.
Each object accepts a different set of permission levels in its role map. For example, rule folders allow groups listed in their role maps to have either Viewer, Editor, Administrator, or Deny permissions, while process models accept those permission levels and two additional ones – Initiator and Manager.
When configuring an object’s security and selecting permission levels, you will note two things. First, that Appian restricts the permission levels you can choose from in the role map based on the object’s type to help ensure that the permission levels you select are applicable for that object type. Second, in most cases when setting object security you will find the need to use only two permission levels: Administrator and Viewer. These can be defined as:
To learn more about object-specific security settings and permission levels, see the security section in each design object’s page.
Users that are members of multiple groups within a role map will always be granted their highest permission. For example, if John Smith is a member of both Group A and Group B, and Group A has Administrator privileges to an object while Group B only has Viewer rights, Appian will treat John Smith as an Administrator.
Many objects offer Deny as a permission level. Giving a group the Deny permission level is equivalent to not listing that group within the role map, or not granting them any permissions. So when does it make sense to use Deny? It’s most useful in situations where a group (Group A) should not have permissions to an object but might be nested within another group that should have permissions to it (Group B). In these situations, marking a group (Group A) with the Deny permission will overrule all of its other permissions.
When an object inherits its security from a parent object, it means that it shares the same role map as its parent. When this is the case, any changes that are saved to the parent object’s security role map are immediately reflected in the child’s inherited role map.
During application development, inheritance can be observed with top-level objects such as knowledge centers and rule folders. Knowledge centers and rule folders are considered top-level objects because their security is inherited by all objects nested within them by default. For example, security set on knowledge centers is inherited by all nested document folders and documents by default. Likewise, security set on rule folders is inherited by all nested rule folders and rule objects including interfaces, constants, expression rules, decisions, and integrations by default. The following two images illustrate this second example.
This first image shows the security role map for ABC Rule Folder. Note that ABC Rule Folder is a top-level object because it does not have a parent object.
This second image shows the security role map for ABC_myFirstInterface. Note that it inherits its security from its parent ABC Rule Folder, and thus has the same security role map as its parent.
Inheritance in object security dialogs is always displayed as an option underneath the Parent field. Objects that must inherit their security from a parent object will display the option as disabled, while objects that cannot inherit security will not display this option.
See the following section for a detailed list of which object types always, optionally, or never inherit security from parent objects.
Appian recommends that you set security on your top-level knowledge centers and rule folders within applications and allow the objects nested below these folders to inherit security. Doing so ensures that security is consistent and easy to manage across large applications.
Process model folders differ from knowledge centers, rule folders, and document folders in that their security is never inherited by nested process model objects. During development, each process model will require that its own security be set.
The following table outlines the behavior of security inheritance by object type.
|Always Inherit Security From Parent||Always Inherit Security If Parent Specified||Inherit Security From Parent By Default (Editable)||Never Inherit Security||Don't Have Security|
*Documents - Always inherit security from their parent document folders. If a group has access to a document folder, it has access to all of the documents nested within that folder. For this reason, document security is controlled at the document folder level.
*Knowledge Centers - Always inherit security from parent communities if a parent community is specified. Since community objects are deprecated, Appian recommends making knowledge centers top-level objects.
*Groups - Always inherit security from a parent group if a parent group is specified.
*Custom Data Types - Do not have their own security role maps. Since custom data types are always seen in the context of another object, the security of that other object applies. For example, if an interface calls a custom data type, the interface's security will be applied.
*Group Types - Do not have their own security role maps. Group security is used instead.
In Appian, security is layered. This means a user must have permissions to every object associated with an application’s feature in order to see or interact with that feature.
For example, for a user to be able to review and submit an Appian generated task, they must have (at least):
The benefit of applying layered object security is that it is possible to implement strict security models, and control security to objects and features at a granular level. Appian recommends regularly testing your applications, and reviewing their Security Summary to ensure that the appropriate users have the appropriate permissions to all of your applications and their features.
Security and visibility are two distinct concepts in Appian. Whereas security is always specific to an object (such an interface or process model), visibility is typically dependent on an expression. Visibility allows developers to provide granular instructions about which groups or users should be able to see and interact with a specific aspect of an object.
For example, a site might have three Viewer groups in its security role map. In this case, a developer can use visibility expressions on the site’s pages to determine which of these groups should and should not be able to see the pages available on the site.
Similarly, a record type could have many Viewer groups, but a developer could specify that only one group is allowed to use the record related action by providing a visibility expression.
It is important that developers set security on each object within an application, including the application object itself. Doing so ensures that developers and application users have the appropriate permissions to the different objects and features of an application.
Appian ensures that each object within an application has appropriately configured security by:
The following sections delve into these available processes in greater detail.
Appian recommends assigning each object at least one Administrator group in its security role map. While administrator permissions are unique per object type, generally administrators are the only ones that can delete an object or modify its security.
Appian also recommends assigning each object at least one Viewer or Editor group, with the exception of feed and group objects because feeds share the same viewers as the application in which they reside (learn more) and groups only accept the Administrator permission level.
You can access and edit an existing object’s security at any time by selecting the object in the application list view, and selecting Security in the toolbar.
Appian will remind you to set object security when creating new objects that do not inherit security from a parent by default. For example, after clicking the Create button for a new process model, Appian will ask you to review and set your process model’s security.
The following table provides a detailed breakdown of which objects inherit security by default, and which objects will prompt you to set security during creation.
|Inherit Security By Default||May Inherit Security||Never Inherit Security|
|Will not prompt you to set security during object creation||Will prompt you to set security during object creation if a parent is not specified||Will always prompt you to set security during object creation|
The Security Summary allows you to view the security of all objects within an application in a single place. You can view an application’s Security Summary by selecting Security Summary in the Application settings dropdown menu.
The Security Summary is helpful when:
A - Groupings
The Security Summary displays a list of object groupings (A). Each section has two parts; on the left-hand side there is a role map (B), and on the right-hand side you will find a list of all of the objects with that specific role map (C). Detected warnings appear at the top of each grouping (J).
By default, groupings are sorted in descending order, from groupings with the most objects to groupings with the least. You can reverse this sort order at any time by clicking Switch Sort Order in the top right-hand corner of the dialog (F).
B - Role Maps
The Security Summary groups objects together if all of the following are true:
Note that objects with role maps where at least one row is inherited from a parent are grouped separately from objects with role maps where no rows are inherited. This is the case even when both role maps have the exact same groups and permission levels specified. This behavior is exemplified in the image above where you can see that both the expression rule and interface that inherit security from the same parent rule folder (ABC Rule Folder - in G) are grouped separately from their parent (in C). This distinction makes it easy to determine which objects are top-level objects in an application, and which objects are inheriting security.
Although the Security Summary arranges objects with the same groups and permissions together, remember that these permissions may have different meanings for each object. For example, to run a web API a user must have Viewer access or be a member of a group with viewer rights, but anyone can evaluate any expression rule if it's invoked by an interface or process model they are using.
C - Objects
To the right of a role map, the Security Summary provides an overview of the grouped objects. To see more details about these objects, such as when it was last modified or whether it has object-specific warnings, click Show Details (C). Objects which inherit security from a parent will have their parent object linked in the details grid (G).
D - Editing
You can edit a role map at any time by clicking the Edit button (D). Any security configurations you edit and save here will be applied to all objects listed to the right of the role map, with the exception of those objects where specific security configurations are not applicable. For example, imagine in the image above that a user added a row to the top-most role map that granted the ABC Sales Team group Initiator permissions. Only the listed process model ABC Start Sales Offer would have this row added to its security role map, as only process model objects recognize the Initiator permission level.
Filters at the top of the page (E), specifically the object type filter, can help you narrow object groupings so that you can edit a smaller subset of objects at a time. If you need to edit a single object’s security but don’t want to leave the Security Summary, you can make the change in a separate tab and click the refresh button (H) in the Security Summary header to see your latest changes.
E - Filters
To help you narrow down the summary view, you can use the filters at the top of the dialog. These filters can be used in any combination to:
The following table lists the different security warnings that may be shown in object security dialogs or in the Security Summary.
|Warning||Applicable Object Types||Additional Information|
|Individual user detected. Appian recommends only using groups to configure security.||All objects||Only using groups makes it easier to manage security because you can easily add or remove a user to a group, which automatically updates all of the role maps that reference that group. Additionally, not all users exist on all environments. Using groups ensures that users have the appropriate permissions to objects as objects are pushed to higher environments.|
|Missing administrator group. No basic users will be able to administer this object, which includes editing its security or deleting it.||All objects||It is a best practice to assign at least one Administrator group to each object to ensure that developers other than the object’s creator will be able to administer the object.|
|Missing viewer or editor group. No basic users will be able to see or make changes to these objects. This extends to both Appian Designer and Tempo or sites, where it applies.||All objects excluding feeds, groups, and unpublished applications||It is a best practice to assign at least one Viewer or Editor group to each object to ensure that developers and users will be able to access and view the object.|
|Duplicate entries detected. A group or user should only be listed in the role map once.||All objects||To avoid confusion and make certain that Appian grants a group or user the appropriate permission level, you should only list a group or user in the role map once. If Appian detects the same group or user in the role map more than once, it will always assign that group or user their highest permission level.|
|Default set to administrator. Selecting administrator as the default allows all users to administer this object, including anyone listed in the role map with a permission level other than Deny. Appian recommends giving administrator access to specific groups instead.||Objects where ‘Default (All Other Users)’ can be set to Administrator||This warning will display when the ‘Default (All Other Users)’ row of the object’s security role map is set to Administrator, AND there are other users and groups listed in the role map with Viewer or Editor permissions. This is because the ‘Default (All Other Users)’ Administrator permission will be granted to all groups and users in the role map other than those with explicit Deny permissions. Appian recommends that you do not give ‘Default (All Other Users)’ Administrator permissions, and instead grant specific groups administrator rights.|
|Parent has security warnings. View and update the parent’s security to resolve inherited warnings.||All objects that can inherit security||This warning indicates that one of the object's parent objects has specific warnings that need to be addressed. Appian recommends addressing the specific warnings on the appropriate parent so that all other objects nested below that parent will also receive the same update. You may have to trace through several layers of inherited security to find the root parent on which the specific warnings first appear.|
|Logged in user not administrator. You currently do not have administrator permissions for this object. Make sure to add yourself to an administrator group in this role map before continuing.||All objects that do not inherit security||This warning is only displayed when you are logged in as a basic user and are creating an object that does not inherit security from a parent. This warning indicates that you have removed yourself as an Administrator of the object and will not be able to delete the object or update its security after creation.|
|Knowledge center default set to viewer. Selecting viewer as the default allows all users to view this knowledge center, excluding anyone listed in the role map with a different permission level. This also applies to the documents and folders that inherit from it. Appian recommends giving viewer access to specific groups instead.||Knowledge centers||It is a best practice to grant specific groups Viewer rights to knowledge centers rather than setting ‘Default (All Other Users)’ to viewers. Doing so ensures that document folders and documents nested within knowledge centers have explicit viewers set.|
|Missing a group with at least initiator permissions. No basic users will be able to start this process model as an action or related action.||Process models||Appian will display this warning on a process model if it detects that the process model is being used as either an application action, record related action, record list action, or site action and has no Initiator, Viewer, Editor, or Manager group specified. This indicates that no basic user will be able to start this process model.|
|Missing a group with at least initiator permissions. Appian has detected that this process model may be used as an action or related action. If that is the case, no basic users will be able to start this process model without having at least initiator permissions.||Process models||Appian will display this warning on a process model if it detects that the process model is referenced by a constant or decision. In this case Appian cannot guarantee that an Initiator, Viewer, Editor, or Manager group is required because it does not know how you intend to use the process model. If you are planning to allow users to start this process model, add groups with one of the previously described permission levels.|
On This Page