17.1 Long-Running Workflows: Persistence, Suspend and Resume

17.1 Long-Running Workflows: Persistence, Suspend and Resume

Core Concept: A long-running workflow can stop in the middle, free its robot, and continue later, possibly on another robot, when something it waits for has happened: a person completes a task, another job finishes, a queue item is processed, or time passes. The exam description lists long-running workflows under attended and human-in-the-loop topics.

---

Setting Up a Long-Running Project

• Start from the Long Running Automation template (formerly Orchestration Process), or turn on Supports Persistence in Project Settings.
• Add the UiPath.Persistence.Activities package.
• In the Main workflow, Delay and Retry Scope are not supported; use Resume After Delay, or place them inside a No Persist Scope, where no suspension may happen.

---

The Create-and-Wait Pairs

Every persistence pattern pairs an activity that starts something and returns a reference with an activity that waits for it and resumes:

Because start and wait are separate, a workflow can start several jobs, queue items, or tasks first and then wait for all of them, for example with a Parallel For Each of wait activities.

---

What Happens at a Wait Activity

1. The workflow reaches a Wait ... and Resume activity.
2. The runtime persists the workflow's state, and the job moves to Suspended. The robot is free to run other jobs.
3. When the awaited event happens, Orchestrator moves the job to Resumed, and an available robot continues from the step after the wait.
4. By default the job can resume on any available robot and machine. The trigger or job option Keep account-machine allocation on job resumption keeps the original pair.

Consequences to design for:

• Everything in scope at a wait must be serializable. UI element handles, open file streams, and database connections are not; close them before the wait and reopen them after.
• Local files may not exist after resuming on another machine. Keep files in storage buckets or other shared storage.
• Recording captures only the execution after the resume.
• Remote debugging of long-running workflows works only with an Unattended Robot connection.

---

Orchestrating Other Automations

Long-running workflows are often coordinators:

Main (long-running)
 ├─ Add Queue Item and Get Reference  → invoice item for the performer
 ├─ Wait for Queue Item and Resume    → job suspends until the item is processed
 ├─ Create App Task                   → approval task with the performer's output
 ├─ Wait for App Task and Resume      → job suspends until the approver submits
 └─ Start Job and Get Reference / Wait for Job and Resume → posting process

The coordinator never holds a robot while people or other processes work. Each step's output feeds the next step.

---

Timers and Deadlines

• Resume After Delay suspends the job for a duration or until a date, without occupying a robot.
• To enforce a response deadline on a human task, UiPath offers a task timer (the Configure task timer activity) in the persistence package. A common pattern is also a Parallel activity with a wait branch and a Resume After Delay branch, with a CompletionCondition that ends the other branch when one finishes.

---

Worked Example: Supplier Onboarding

1. A form arrives, and the coordinator adds a verification queue item with Add Queue Item and Get Reference.
2. Wait for Queue Item and Resume suspends the job while an unattended performer checks the supplier's tax ID and bank details.
3. The coordinator reads the item's output. If checks failed, it creates a form task for the compliance team and waits for it.
4. If checks passed, it starts the ERP setup process with Start Job and Get Reference and waits for it with Wait for Job and Resume.
5. Finally it sends a welcome email.

Across the whole flow, the coordinator occupies a robot only for the few seconds between waits, although the onboarding may take days.

---

Common Traps

• Using Delay in the Main workflow of a long-running process instead of Resume After Delay.
• Keeping a UI element or DataTable of non-serializable objects in scope across a wait.
• Expecting the job to resume on the same machine without enabling the account-machine allocation option.
• Waiting for each task right after creating it when several tasks could be created first.