Application security is an important concept you need to know to give users the appropriate permissions within an application. This page covers the fundamental concepts about application and object security as it relates users of the application. More information about object-specific security settings can be found on its particular design object page.
New applications created in Appian Designer add the creating user to the role map with administrator permissions. Having permissions to an application does not give the designer permissions to the objects associated with an application. Users in Tempo must be at least application viewers to see the actions or feeds of a published application.
See the App Security Table for the roles and permissions that can be applied.
Appian's security paradigm is extremely powerful, yet flexible. Because of this flexibility, it can initially be difficult to grasp the details of how to properly secure your applications. The following concepts will help clarify your understanding of the Appian security model.
What should people (groups) be able to do (rolemap) with this object?
When Appian invokes an object's security model, members of a group are allowed to take certain actions on that object based on the permission level in the role map.
Let's look at an example process model security dialog to see these concepts in action.
In the above example, CMF Designers have administrative privileges to this model while CMF Users only have Viewer access to the process model. Notice each group has a different permission level on the process model, resulting in a flexible role map.
It is a best practice to only use groups when setting object security. This allows you to control object access by changing a user's group membership, rather than editing the object role map each time.
Most object types have different permission levels in their role map, which is tailor-fit for that object. For instance, a Process Model may need to allow users to start a process, but restrict them from process data moving forward. For this reason, models have an initiator permission level as part of its role map.
With up to five permission levels per object type, and a wide range of different objects, you can set security to match even complex configurations. However, in most cases, you will find that objects typically require only two permission levels:
Administrators - The group or groups whose members have administrative privileges for this object in this environment. This includes full edit and delete privileges for an object.
Viewers - The group or groups whose members can interact with a particular object from an end user state (Tempo, Sites, or Embedded). For example, have viewer rights to an interface will grant group members the permission to view and interact with that interface.
Applications and Record Types have a global option for viewers. If desires, designers may grant anyone in Appian Viewer access to one of these objects.
The viewer permission level provides interactive access for all objects excepts for document management-based objects. For Knowledge Centers and Folders, Viewer access only provides read capability.
For users that are members of multiple groups within a role map, Appian will automatically grant object access at the highest level.
Many objects also contain a Deny permission level. This permission level is special insofar as it is functionally equivalent to a user not being in the role map. However, Designers may find it useful for situations when a user might be in a group that normally has permissions to the object. In these cases, the Deny level will trump all others.
Folders allow for security inheritance of object, and other folders within them. This allows Designers to set top-level security at a Rule Folder or Knowledge Center, and any objects within it will automatically get set without any further action.
Because the security role maps of Process Models and Process Model Folders differ, Process Models will not inherit any permissions from it's folder.
For example, our top level Rules and Constants Folder has security set.
But child object will automatically inherit security from this top level folder.
Because these objects are never seen outside the context of another object, they rely on the other object's permissions. Additionally, while Documents do not have their own security, their folders do. If a group has access to that folder, they will have access to the contents of that folder. Security can be configured in such a way as to limit which documents are seem strictly through the folders that they are in.
Object security is layered like an onion. In order for a user to gain access to an application's feature, they must have the appropriate permissions for every object associated with that feature.
For example, if a case worker was assigned a task to review a customer service request.
In order to see and submit the task, our case worker must have (at least):
This approach provides the opportunity for very granular user access.
There is an important distinction between security and visibility. Where security is specific to the object, visibility is typically dependent on certain data parameters. For instance, a user could have viewer access to a record, but not have access to a related action within that records.
The visibility field when configuring the related action dictates this, and is dependent on evaluating an expression.
Similarly, a task assignment could be seen as visibility, giving access to a particular task only to as user or set of users.
In both cases, data is the underlying component of visibility as opposed to security, which is solely related to the permissions level granted in an object's role map.