Decide who owns the work
This guide is for authors who want work to reach the right people without anyone sorting it by hand. It covers who gets the work first, who gets it next, and what happens when that is an agent. To see the work from the reviewer’s side, read Escalations and approvals.
Say who owns the work
Section titled “Say who owns the work”- Add Set Assignees before the work it should cover, and connect it. It sends nothing outside Lainstack, and the run continues through its Out exit.
- Under Decisions, choose who handles approvals and corrections. The first entry is Assign to, and each entry after it is Then.
- Under Technical, choose who handles failures. If you leave it empty, failures use Decisions.
Each list holds up to 10 entries. An entry can be:
- A person, a team or an agent.
- A value from the run that names a person or a team, such as an account owner’s email address. Run data can never name an agent. A value that is empty or names nobody is skipped, and the run carries on.
Publishing is refused when an agent in a list has no Failure work ticked under Workspace access on its own automation’s AI Agent block. Tick it and publish that automation first.
Without a Set Assignees block, an escalation has no assignee and waits in the Workspace queue.
Give each branch its own owners
Section titled “Give each branch its own owners”Work goes to the first assignee of the last Set Assignees block it passed. Parallel branches keep their own owners, so a block on one branch changes nothing on another.
Two limits to plan around:
- A case copies the list when it opens, so publishing a change does not affect a case that is already open.
- The block cannot run inside the item branch of For each item. The step fails there. Put it before the loop, and the items use the assignees of the branch that started it.
The block runs in draft runs too, so you can test your routing before you publish.
Move work on with a timer
Section titled “Move work on with a timer”Each entry has a Move on setting that passes the work to the next entry:
| Move on | Means |
|---|---|
| No timer | The entry keeps the work until someone acts. The default for a person or a team. |
| After a duration | From 1 minute to 1 year. An agent has After 30 minutes, the default instead. |
| At a time from the run | A date from an earlier block. A time that has already passed moves on at once. |
A timer only changes who has the work. It ends nothing, so a run waiting on an approval keeps waiting, and the Approval block’s own timeout still ends the wait. For a person or a team, a time from the run that turns out empty means no timer. An agent that starts by itself always has a deadline, so it gets 30 minutes if that time is empty or has already passed.
People can change what the timer does on a case:
- Claiming a case stops its timer, and unclaiming starts it again.
- Assigning someone by hand restarts a duration, so the new person gets a full window. A time from the run stays as it was.
When an agent comes first
Section titled “When an agent comes first”What an agent does when it is first in a list depends on the work.
| Work | What the agent does |
|---|---|
| An approval or a correction | Is assigned and does not start. |
| A failure group | Starts by itself after 10 minutes, unless someone acts first or one of the reasons below applies. |
For an approval or a correction, a person starts the agent from the Assigned to menu, as their own turn with their own approval cards.
Failure groups
Section titled “Failure groups”An agent that is first in Technical, or first in Decisions when Technical is empty, gets a failure group when it opens. The 10 minutes give people a chance to act first, and assigning the group or working on it during that time means the agent does not start.
Nobody asked for this turn and nobody is watching it, so the agent can do less than it can in a chat:
- It reads the group, the automation and that automation’s runs, and no other automation.
- It records a diagnosis and can store a proposed change. Test the proposal then tests the change with reads and writes held.
- It cannot change your draft, publish, resume, dismiss or merge groups, and it cannot use tools from connected servers.
The agent does not start, and the work moves to the next assignee, when:
- No run in the group still fails.
- The automation that failed runs an agent itself, so an agent’s failure cannot start another agent.
- The agent’s own automation does more than run the agent.
- The agent is not available to start by itself.
- Someone has already worked on the group.
- An agent looked at the group in the last 24 hours.
- The agent has reached its daily limit.
The group records each of these as a line, so you can see why the agent did not look. If nobody comes after the agent, the work stays assigned to it and a person can still pick it up.
To keep an agent from starting by itself, put a person or a team first in Technical and the agent after them.
Change who has one case
Section titled “Change who has one case”The Assigned to menu on an escalation or a failure group changes that case only, and the block stays as it is. See Who gets it and Assign a group.
Try it
Section titled “Try it”A draft run that reaches an Approval block raises a real escalation. Run the draft down each branch, open Escalations, and check who each one went to.