Application Configuration and Deployment
What you must know
An application groups objects (record types, process models, interfaces, groups, integrations) into a deployable unit. Understand application objects versus dependents, and how application versions work. Know the deployment pipeline: create a package, inspect deployment errors/warnings, deploy to target environment, and verify. Understand import customization files for environment-specific values and object security during deployment.
Know environments (dev, test, prod), data store configuration per environment, and how connected systems and integrations are configured. Understand application documentation and object naming conventions. Know that groups and users are often environment-specific and must be mapped during deployment.
Traps
- Assuming all dependents deploy automatically; some must be added manually.
- Forgetting that environment-specific values (URLs, credentials) need import customization files.
- Confusing application version with process model version.
- Overlooking that security on objects can block deployment or access post-deploy.
- Deploying without checking deployment warnings that indicate missing dependents.
Rule of thumb
Before deploying, confirm every object has its dependents, every environment-specific value is externalized, and every group referenced exists in the target. Treat warnings as errors until proven harmless.
Worked example
Deploying a process model that calls an integration: add the integration and its connected system as dependents, externalize the endpoint URL in an import customization file, map the assignment group to the target environment's group, then inspect warnings before deploying.
Security
What you must know
Appian security is layered: authentication (who you are), authorization (what you can do), and object security (who can see/edit each object). Know groups (nested, with membership rules), roles, and object security roles (viewer, editor, administrator). Understand record-level security (row filters) and field-level security (column permissions). Know process instance security and task assignment as separate controls.
Know administrator vs designer vs user roles, and how security expressions (e.g., loggedInUser(), isUserMemberOfGroup()) work. Understand data store security and integration credentials. Know SSO and authentication basics.
Traps
- Assuming object security and record-level security are the same; they are not.
- Forgetting that a user can see a record type but not all its rows.
- Believing group membership is flat; nested groups inherit.
- Overlooking that task assignment does not grant record access by itself.
- Confusing role (system) with group (custom).
Rule of thumb
Ask three questions for any security scenario: Can the user authenticate? Can the user access the object? Can the user see the specific row/field? A "yes" at one layer does not imply the next.
Worked example
A support agent should see only tickets assigned to their team. Grant the group view access to the Ticket record type, then add a record-level filter team = loggedInUser().team. Object access alone would expose all rows, so the filter is required.