7.2 User Input Tasks, Activity Chaining & Assignment
Key Takeaways
User Input Tasks assign interactive SAIL interfaces to human users or groups, supporting task display expressions, deadlines, and automated escalation actions.
Editable task form rule inputs map through ac! node inputs, with configured saves back to pv! process variables.
Activity chaining defaults to 50 unattended node instances between attended forms; five seconds is discouraged long-chain latency, not a universal hard timeout.
A shared assigned task can be accepted by an eligible user, reserving it for that user under its assignment configuration.
Task escalations automate SLA enforcement by triggering timers that can dynamically increase task priority, send notification alerts, or reassign overdue tasks to supervisory groups.
User Input Tasks, Activity Chaining & Assignment
Quick Summary: User Input Tasks (UIT) represent attended workflow steps where human actors interact with Appian SAIL interfaces to review, enter, or approve business data. To ensure an intuitive user experience, developers utilize Activity Chaining to navigate users seamlessly from one screen to the next without kicking them back to task lists or landing pages. Mastering task assignment lifecycles, interface rule input mapping, escalation rules, and the strict technical limits of activity chaining is essential for enterprise workflow design.
User Input Task Configuration and Data Flow
Select the interface on the task's Forms tab. For values the user edits, map interface rule inputs to node inputs (ac!), initialize them from process variables as needed, and configure the node-input or output save back to the intended process variable (pv!). Read-only process values can be passed directly for display; they are not editable process-variable targets from the task form.
| Stage | Example |
|---|---|
| Before task | pv!customer contains the existing customer |
| Node initialization | ac!customer receives the intended initial value |
| Forms mapping | ri!customer is mapped to ac!customer |
| User edits | Component saveInto updates the interface input/node input |
| Task completion | Configured save maps the result into pv!customer |
Check types and single-versus-multiple settings at every boundary. A local variable that displays edited text but never saves it into the mapped input will not update the process. A mapped node input without a save to a process variable will not supply that edited value to later nodes.
For example, a review form accepts customer, decision, and comments inputs. Map edited customer and comments through node inputs; pass any immutable reference details for display. On submission, save the decision and comments to the process variables used by the following gateway and persistence step. Inspect the actual variables in a test process to confirm the mapping.
When an interface gains or loses inputs, refresh its task-form mappings and review the node's Data tab. Do not assume that a new text field automatically creates the complete data path. Avoid competing input and output saves into the same process variable, which can overwrite the intended result.
Configure the task display name, assignment, deadlines, and escalation requirements separately. A working data mapping does not establish that the correct user receives the task, and a correct task assignment does not prove its returned data is saved.
Task Assignment & Group Lifecycle Mechanics
Appian enforces a structured task lifecycle to coordinate work across operational teams:
+-----------------------------------------------------------------------------------+
| TASK ASSIGNMENT & ACCEPTANCE LIFECYCLE |
| |
| [ User Input Task Generated ] |
| | |
| v |
| ( ASSIGNED TO GROUP: Claims Reviewers ) |
| | |
| v |
| STATUS: "ASSIGNED" ---> Appears in task list of ALL group members |
| | |
| +---> [ User A clicks "Accept" ] |
| | |
| v |
| STATUS: "ACCEPTED" -> Task reserved exclusively for User A; |
| Removed from task queues of other group members |
| | |
| +---> [ User A clicks "Reject" / Releases Task ] |
| | Task reverts to "Assigned" for the group pool |
| v |
| [ User A Submits Form ] ---> STATUS: "COMPLETED" |
+-----------------------------------------------------------------------------------+
Task Lifecycle States
- Assigned: When a task is assigned to an Appian Group, it enters the "Assigned" state. It appears in the task queue of every eligible member of that group.
- Accepted (Assigned to Individual): When a member opens and accepts the task, its status transitions to "Accepted". The task is now reserved exclusively for that user, and Appian automatically removes it from the task lists of all other group members to prevent duplicate work.
- Reassignment & Release:
- Self-Release (Reject): If a user accepts a task but cannot finish it, they can click "Reassign" or "Reject" to return the task to the group pool, transitioning its status back to "Assigned".
- Manager Reassignment: Application administrators or task supervisors can explicitly reassign a task to another user or group at any time via Process Monitoring.
Activity Chaining: Architecture & Technical Constraints
In standard process execution, when a user completes a start form or task form, Appian navigates them back to the Site page or Tempo task list. However, modern business applications often require a contiguous multi-step wizard experience (e.g., submitting an application form and immediately viewing the confirmation/next review screen).
Activity Chaining enables this behavior by keeping the user's browser session linked to the execution flow across consecutive nodes:
+-----------------------------------------------------------------------------------+
| ACTIVITY CHAINING EXECUTION PATH |
| |
| [ Start Form ] ===( Chain )===> [ Script Task ] ===( Chain )===> [ Next UIT ] |
| (User Submits) (Calculates) (Renders Form |
| Instantly to |
| Same User) |
| |
| * Connector lines display bold styling with chain link icons |
+-----------------------------------------------------------------------------------+
How to Enable Activity Chaining
Developers right-click the outgoing sequence flow connector between two nodes and select Enable Activity Chaining. Chained flows appear as bold lines with small chain link icons on the canvas.
Chaining Limits and Performance
The default activity-chain limit is 50 unattended node instances between attended forms, configurable within supported bounds. The documented maximum is 100. Exceeding the configured node limit breaks the chain; the process can continue and the next attended task is delivered to its assignee's task list.
Appian strongly discourages long activity chains, including more than about five seconds between attended activities. Five seconds is performance guidance, not a universal hard timeout that always ends the chain. Other execution settings and service behavior also affect the user's wait. Keep chained operations short and measure them with realistic data.
Do not chain heavy external calls or large batch loops merely to force the browser to wait. A background job with a clear completion status may be a better experience. Chaining also does not override assignment: the current user cannot complete a task assigned to someone else.
Deadlines, Escalations & Exception Events
To ensure operational SLAs are met, developers configure deadlines and escalations on the Escalations and Exceptions tabs of User Input Tasks:
1. Task Deadlines
Developers can specify an SLA deadline expression (e.g., a supported task-deadline expression based on the intended task activation time). When a deadline passes, Appian flags the task as overdue in task reports and can highlight it with visual warnings in site dashboards.
2. Task Escalations
Escalations execute automated actions when specific time thresholds expire:
- Priority Escalation: Automatically elevates task priority (e.g., bumping from "Normal" to "Urgent" after 24 hours of inactivity).
- Notification Escalation: Dispatches automated email alerts to supervisors or group managers warning of SLA breach.
- Reassignment Escalation: Reassigns the task from an inactive user back to the general group queue or to an escalation manager.
3. Exception Flows (Skip Paths)
Configured on the Exceptions tab, an exception event listens for external conditions (such as a timer expiring or a cancel message arriving). When the exception triggers, Appian instantly cancels the User Input Task and routes execution down an alternate flow path (e.g., auto-cancelling an unapproved purchase order after 14 days).
Realistic Implementation Scenario: Enterprise Employee Onboarding
A multinational technology firm manages employee onboarding through a multi-step process model:
- Step 1: HR Initiation: HR specialist fills out an attended Start Form with new hire credentials. Activity chaining is enabled on the outgoing flow.
- Step 2: Automated Provisioning: The flow traverses a Script Task that calculates the new hire's corporate email address and prepares the required data; group creation, if required, uses a suitable smart service.
- Step 3: Equipment Selection: Because activity chaining is enabled and the chained work remains short and the next task is assigned to the current user, the HR specialist immediately sees the "Select Hardware & Workspace" form without returning to the home site.
- Step 4: IT Provisioning Task: Submitting the equipment form breaks activity chaining. A new User Input Task "Configure Laptop Image" is routed to the
IT Support Techniciansgroup. - Escalation SLA: The IT task has an escalation configured: if the task remains in "Assigned" status for more than 48 hours without acceptance, its priority elevates to "Urgent" and an escalation alert is dispatched to
IT Support Supervisors.
Exam Traps & Development Best Practices
Warning
Common Exam Trap 1: Forgetting the configured activity-chaining node limit (default 50 unattended node instances). In looping workflows (e.g., iterating through a list of items), chaining through a loop can quickly exceed 50 nodes, causing Appian to break the chain unexpectedly. Use batch operations or a!forEach() inside a single Script Task instead of multi-node process loops.
Warning
Common Exam Trap 2: Assuming activity chaining forces a task to stay with the original user. If an activity chain leads to a User Input Task assigned to a different user or group, the current user cannot see that task. Appian completes the chain for the current user and routes the new task to the assigned user's queue.
Tip
Interface Mapping Rule: When binding interfaces to User Input Tasks, map edited rule inputs through node inputs and configure their save back to the appropriate process variables. Omitting rule input mappings is the leading cause of "missing form data" defects in Appian applications.
Source checked 2026-10-18: Appian process data flow.
Which statement correctly describes Appian activity chaining?
It cannot cross script tasks
It permits unlimited unattended nodes
It changes task assignment to the current user automatically
It has a configurable unattended-node limit, defaulting to 50; long waits should be avoided
An insurance claim approval workflow generates a User Input Task assigned to the "Claims Adjusters" group. What occurs when Adjuster Rodriguez opens and accepts the task in Tempo or a Site?
The task transitions from Assigned to Accepted status, reserving it exclusively for Adjuster Rodriguez and removing it from the task queues of all other adjusters
The task is duplicated across all group members so that each adjuster must independently submit an approval
The workflow automatically terminates the parent process model and spawns a synchronous sub-process
Adjuster Rodriguez is temporarily removed from the Claims Adjusters group until the task is submitted
How does editable task-form data reach later process nodes?
By reading browser storage from a database trigger
Map interface inputs through node inputs and save the resulting values into process variables
By placing pv! variables directly inside the reusable interface
By replacing every input with pp!initiator
Sections you finish are checked off in the contents.