Appian Process Models Interview Guide

A Process Model is the diagram Appian runs to automate a business process: what happens, in what order, and under what conditions. It is built from a Start Event, activity nodes (User Input Task, Script Task, Write to Data Store Entity and so on), gateways (XOR, AND, OR), sub-process nodes, End Events, and the connections between them. Process variables carry data from one node to the next.

An XOR (exclusive) gateway sends the flow down exactly one outgoing path, chosen by a condition, much like an if-else. An AND (parallel) gateway sends it down every outgoing path at once, so the branches run in parallel. If you split with an AND gateway, you need a matching AND gateway to merge the branches before the process continues.

Every activity node has an Exceptions tab where you add an exception event: a Timer (stop the activity after a set time), a Rule (stop it when a condition becomes true) or a Receive Message (stop it when another process sends a message). The event shows as a marker on the border of the node, and you connect that marker to an exception flow, which the process follows instead of the normal path. An activity can have only one exception flow, and the process initiator gets an alert whenever an exception fires. Exception events do not catch a failing smart service: by default that node pauses by exception. Some nodes let you handle it in the flow instead. Write Records, for example, has a Pause On Error input you can set to false, and an Error Occurred output you can branch on. To stop every branch of a process at once, end it with an End Event that has a Terminate Process trigger.

A process variable belongs to one process instance, so every running process has its own copy. It lives as long as the process does, and any node can read or write it. Use them for data that changes per case: user input, intermediate results, IDs. A constant is a read-only value defined once in the application and shared by every process, which suits fixed configuration such as URLs, thresholds and status codes.

A sub-process is a separate process model that a parent process calls. Reach for one when the same steps appear in more than one process, when a diagram has grown too big to read, or when independent pieces of work should run in parallel, since each sub-process runs as its own instance. A synchronous sub-process makes the parent wait until it finishes; an asynchronous one lets the parent carry on straight away.

There are two ways to use time in a process. A Timer exception on a task's Exceptions tab stops the task once a set time has passed and sends the process down the exception flow, for example to reroute an approval nobody has touched in 24 hours. If you want to act on a slow task without cancelling it, use the Escalation tab instead: it can reassign the task, change its priority, send an alert or send a message to another process. A Timer Event placed in the flow pauses the process for a fixed duration or until a date and time, for example before sending a reminder email after 48 hours.

A Script Task is an unattended node that evaluates an expression or rule and saves the result into process variables through its node outputs. It is the usual place for calculations and data shaping between other nodes. Writing to a database is a job for a smart service node instead: Write to Data Store Entity writes CDT data through a data store, and Write Records writes record type data. A script task cannot do the write itself.

Split the flow with an AND gateway so each approver gets their own User Input Task in a parallel branch. A second AND gateway merges the branches; it waits for every incoming path, so the process continues only when all approvals are in. If X of N approvals is enough, merge with a Complex Gateway instead and set it to require that many incoming paths. Save each decision to a process variable, and have a script task after the merge work out the final result.