Security and Access Control
Layered security
Appian security operates at several layers: authentication (who you are), authorization (what you can do), and data visibility (what you can see). Object security uses role maps - Administrator, Editor, Viewer, and custom roles - applied to folders and objects. Groups are the unit of assignment; users inherit through group membership.
Records and row-level security
Record types support record-level security through a security expression that filters rows per user. This is distinct from object security, which controls whether a user can open the record type at all. Process security controls who can start, view, or administer a process.
Traps to watch for
- Confusing object security (can I see the record type?) with record-level security (which rows can I see?).
- Assuming folder permissions override object permissions. Inheritance flows down, but explicit object role maps can differ.
- Forgetting that process model security governs who can start an instance, separate from task assignment.
- Believing a user in an administrator group automatically sees all data. Admin rights are about configuration, not row visibility.
- Overlooking that service accounts and connected system credentials have their own permissions.
Rule of thumb
For any security question, name the layer: authentication, object authorization, process authorization, or row-level filtering. Most distractors are correct at one layer but wrong at the layer the question asks about.
Worked example
A manager can open a record list but sees only their own team's rows. Object security grants access to the record type; the record-level security expression filters by team. To broaden visibility, change the expression - not the role map.