Appian Platform Fundamentals and Architecture
The object model is the architecture
Appian is best understood as a set of design objects that are versioned, stored in a shared application, and executed by the platform runtime. The core object types are interfaces, process models, record types, data stores, integrations, sites, groups, constants, decision objects, and folders. Every object has a security role map, and almost every object can be reused across applications.
Environments and the package boundary
Objects live in environments (development, test, production). Movement between them happens through application packages or deployment pipelines. A key architectural fact: object references travel as UUIDs, so an object moved into a target environment resolves to the target copy of any dependency, not the source copy. This is why dependency analysis matters before deployment.
Traps to watch for
- Confusing process models (execution logic) with records (data access layer). A record does not "run"; it exposes data through record types and views.
- Assuming a constant is environment-specific by default. Only certain constant types carry per-environment values; plain constants deploy with the package.
- Believing the Admin Console configures application logic. It governs environment-level settings such as users, groups, and system configuration - not design objects.
Rule of thumb
When a question asks where something "lives," answer at the right layer: design objects live in applications; runtime state lives in process instances and the data store; environment settings live in the Admin Console. If an answer mixes layers, it is usually wrong.
Worked example
A developer asks why a moved integration points to the wrong endpoint. The integration references a constant. In the target environment, that constant resolves to the target value - so the fix is to verify the constant's value in the target environment, not to re-import the integration.