Administration, Security, and Deployment
Administration
What to know
The Administration Console holds system-wide settings, separate from application design. Expect questions on managing users and groups (creating, deactivating, nesting), monitoring process instances and running health checks, reviewing logs, configuring authentication and password policy, and checking system and usage information. Group design matters: membership in nested groups cascades into permissions everywhere, so a careless nesting decision hands out broad access.
Day-to-day operations on running work - inspecting a stalled instance, checking process variables, intervening in a node - belong to process monitoring and the Process Inspector, not to interface or data design.
Traps
- Deactivate, do not delete. Deactivating a user preserves audit history and object ownership; deletion is destructive and rarely the right answer.
- Users inherit permissions from every group they belong to, directly or through nesting; effective access is the union.
- The Administration Console is for system settings; an object's security is changed in the designer.
- A slow form is usually an interface or query problem, not a system setting - check expressions and queries before blaming the environment.
Worked example
A new hire cannot see an application. Work outwards: is the account active, is it in the correct group, does that group (directly or via nesting) hold a role on the application and its objects, and does record-level security allow the rows? Each layer is a separate check, and fixing only the outermost one is rarely enough.
Rule of thumb: troubleshoot access from the user outward - account, group, object role, row-level filter.
Security
What to know
Appian security is additive. Roles are granted to users and groups on each object, and a user's effective permissions are the union of everything granted to them, directly or through nested groups. There is no explicit deny - a frequent exam trap. Object security protects the design object; for record types you also get record-level security (a filter expression evaluated per row to decide which records a user may see) and field-level security for individual fields. Process models and their instances carry their own security settings, and sites restrict pages to groups.
Authentication configuration - SAML, LDAP, password policy - lives in the Administration Console, not in the application.
Traps
- 'Deny' is not a concept in Appian; you restrict by removing a grant, not by adding a negative one.
- Object-level Viewer access does not grant row visibility; record-level security still applies.
- A user in a nested group inherits that group's grants - check nesting before concluding a permission is wrong.
- Securing an interface does not secure the process that calls it, and vice versa.
Worked example
An HR record type where managers should see only their own team. Grant the HR group Viewer on the record type (object security), then add a record-level security expression that compares the record's team field with the logged-in user's team and returns true only for matching rows. Two layers, two purposes: one controls the object, the other controls the row.
Rule of thumb: grant the smallest group possible at the object level, then narrow rows with record-level security.
Deployment
What to know
An application bundles the design objects that make up a solution, and deployment moves those objects from one environment to another (typically dev to test to production). When you deploy, Appian packages the selected objects plus their dependencies - record types, constants, interfaces, process models, groups - so the target environment has what it needs. Process instances and data are not deployed; only the design travels. Environment-specific configuration should live in constants so it can differ per environment without redesigning objects.
Before deploying, compare source and target to see what will be created or overwritten, and afterwards verify that record types resolve their data sources, constants hold the right values, and security roles are granted in the target.
Traps
- Overwrite semantics. Deploying an object replaces the target version, so local hotfixes can be lost.
- Missing dependencies usually mean an object was not included, or a data source or group does not exist in the target.
- Data and running instances do not travel; database schema changes must be applied separately.
- Security may not arrive as you expect - confirm the groups exist and the role map is correct in the target.
- Skipping the test environment is almost always the wrong answer in a scenario question.
Worked example
Promoting a new record type: select it in the application, review the dependency list (data store, data source, interfaces, related record types), deploy to test, exercise the record list and one process end to end, then repeat to production. If the list is empty in test, suspect the data source or row-level filter before blaming the deployment.
Rule of thumb: deploy objects and dependencies, then verify data, configuration and security in the target - deployment moves design, nothing else.