Appian ACD201 common mistakes
Appian ACD201 · Understand the traps and how to avoid them.
Treating a one-to-many relationship as a plain text field on the parent record instead of creating a child record type with a reference field back to the parent, then discovering the child data cannot be queried, filtered, or reported on independently.
Candidates model from the UI they picture (a form with a few extra inputs) rather than from the data relationships, so they collapse a real entity into a column to avoid creating a second record type.
What to do instead
Before building any object, list the entities and their cardinality, and create one record type per entity with reference fields for relationships; use a one-to-many reference from the child to the parent rather than embedding data in the parent.
Setting a record type's data source to a database view or query entity and then expecting users to be able to create and edit records through that record type.
Views and query entities are read-only by nature, but the record type wizard accepts them without complaint, so the read-only limitation only surfaces when a form fails to save.
What to do instead
Use a database table or web service as the source for record types that need writes; reserve views/query entities for read-only reporting record types, and confirm the write path with a test create before building the interface.
Building a process model where the user input task and the subsequent script task are separated by an AND gateway that never converges, leaving the process stuck or requiring duplicate paths.
Candidates add gateways reflexively to 'show the flow' without understanding that a single sequential path needs no gateway, and that parallel paths must be explicitly merged.
What to do instead
Use gateways only for genuine branching or merging; for a linear flow, connect activities directly. When splitting with an AND gateway, always pair it with a matching converging AND gateway, and trace every path to an end node before publishing.
Configuring a user input task's form but forgetting to map the form inputs back to process variables, so downstream nodes see null values.
The form designer and the process variable mappings are configured in separate places, and the task 'completes' successfully, hiding the missing data until a later node errors.
What to do instead
For every user input task, explicitly map each form field to a process variable (or use a rule input/action with defined outputs) and test the process end-to-end with sample data, checking variable values in the process instance after each task.
Placing a validation on a field using a saveInto that writes to a local variable, then wondering why the error never blocks submission.
Candidates conflate UI validation components with data validation; validations that are not tied to the submitted data or that run against a stale local variable do not prevent the form from saving.
What to do instead
Tie validations to the same variable the form submits, or validate in the process/save logic (e.g., a script task or record-type validation) so the check runs against the persisted value; test with invalid input to confirm the save is actually blocked.
Using a!forEach to render editable inputs but binding each row to a single scalar variable instead of the array element, so all rows show and save the same value.
The saveInto target is often copied from a non-repeating example, and the misunderstanding of how the forEach item variable scopes to each row leads to a shared binding.
What to do instead
Inside a!forEach, bind each component's value and saveInto to the current item (e.g., fv!item.field) or to the array indexed by fv!index, and verify by editing two different rows and confirming distinct values persist.
Calling an integration from a process or interface without handling the error path, so a failed HTTP call throws an unhandled exception and the process instance errors out.
Happy-path testing with a working endpoint hides the failure mode, and the integration object's error handling is a separate configuration step candidates skip.
What to do instead
Configure the integration's error handling (e.g., return an error response or throw a configured exception), wrap the call in a process node with an error boundary/exception flow, and test with a deliberately failing endpoint or timeout.
Assuming an expression rule or interface can call a web service synchronously without considering that the integration must be published and its connected system configured with the correct authentication.
Candidates test in a designer context where their own credentials apply, then deployment fails because the connected system's authentication or endpoint URL is environment-specific.
What to do instead
Define integrations against a connected system object, configure authentication per environment, and verify the integration is published and callable from a process in a non-designer context before relying on it.
Granting users a group membership that gives object-level access but forgetting that record-level security (row-level) still hides rows, then concluding permissions are broken.
Candidates test with an administrator account that bypasses row-level rules, so the object permissions appear correct while a normal user sees an empty grid.
What to do instead
Test with a non-admin user in the target group, and configure both object security and the record type's row-level security (e.g., a security filter or rule) so the intended rows are visible; verify with a user who should see a subset.
Deploying an application package without including dependent objects (record types, groups, connected systems, constants), causing the deployment to fail or the target environment to reference missing objects.
The deployment wizard lets you select a subset, and object dependencies are not always obvious, so candidates package only what they edited.
What to do instead
Use the dependency analysis/compare features to include all required objects, deploy to a lower environment first, and inspect the deployment log for missing-object errors before promoting to production.