The most common way work stalls isn’t that nobody can do it — it’s that it went to one person who was busy, away, or never saw it. Atlas’s operations features are designed around a different default: work goes to a team, and anyone on that team can pick it up.
Work queues
When an Atlas pipeline needs a person — for example, a directive that requires human sign-off — it creates a queue entry scoped to a role, not an individual.
- Directives that need human sign-off create queue entries automatically.
- Team members open the queue for their role and claim an item to work it.
- Completing the work satisfies the directive, and the pipeline advances the stage.
Until someone claims it, the entry waits in the open queue. Nothing silently lands in one person’s inbox and stalls.
Why role-scoped queues work
- Coverage. If one person is out, someone else on the role sees the same queue.
- Visibility. Open work is visible to the whole team, so backlogs are obvious.
- Fairness. People claim what they can handle, rather than having work assigned to whoever was named last time.
- Accountability. A claimed item has an owner for as long as it’s being worked.
Notification rules
A notification rule connects something that happens in your data to the people who should know. Rules map a domain event to a role, optionally narrowed to a specific record schema.
Atlas’s documentation describes three steps:
- Create a rule and pick the event to listen for — for example, a record being created.
- Optionally scope it to a record schema so only relevant events fire.
- Choose the role to notify and a severity. Leaving the scope open notifies on every matching event.
Designing good rules
- Notify roles, not individuals, for the same reasons queues are role-scoped.
- Scope rules to record schemas so people hear about what’s relevant to them. A rule for new Service Request records is more useful than one for every record.
- Use severity deliberately. If everything is urgent, nothing is.
- Start with a few rules and add more as you learn what people actually need to know.
Queues and notifications together
Queues and notifications complement each other. A notification tells a role that something happened; a queue entry gives that role work to claim. A typical pattern:
- A customer submits a service request.
- A notification rule tells the office role that a new request arrived.
- The request’s pipeline reaches a Review stage and creates a queue entry for the office role.
- Someone in the office claims it, reviews it, and completes the directive.
- The pipeline advances.
Designing queues around your teams
Queues are only as useful as the roles behind them. A few guidelines:
- Create roles that match real teams — office staff, field crew leads, dispatch — rather than individual job titles.
- Keep the number of roles small. Every extra role is another queue somebody has to watch.
- Make sure every queue has enough people that work is picked up promptly when someone is away.
- Agree a claiming convention. For example, claim only what you’ll start today, so the open queue reflects genuinely unclaimed work.
A notification plan that people don’t mute
The fastest way to make notifications useless is to send too many. A workable plan:
| Event | Scope | Notify | Severity |
|---|---|---|---|
| New service request record created | Service Request schema | Office role | Normal |
| Request marked urgent | Service Request schema | Dispatch role | High |
| Record created in a module with no owner | — | Administrators | High |
Three rules are usually enough to start. Add more only when someone says “I wish I’d known about that sooner.”
Queue and notification anti-patterns
- Notifying everyone about everything. People filter it out, and the important messages go with it.
- Assigning work to individuals by hand. It recreates the single-inbox problem queues exist to solve.
- Leaving claimed work unfinished. A claimed item is invisible in the open queue, so agree what happens when someone can’t finish.
- Scoping nothing. A rule that fires on every event of a type in a busy system becomes noise.
Measuring how work flows
Two simple measures tell you a lot:
- How long items sit unclaimed. Growing wait times mean a role is understaffed or the queue isn’t being watched.
- How long claimed items take to complete. Long times may mean the directive asks for too much, or the person claiming lacks what they need.
Both are questions about process design rather than about individuals, which is exactly the conversation role-scoped queues make possible.
Frequently asked questions
Can one person be in several roles? Yes — they’ll see each role’s queue.
What happens to a claimed item if someone leaves? Work that needs to return to the team can be handled by your own convention; the queue exists so it can be picked up by someone else on the role.
Do notification rules cost anything to run? They’re part of Atlas’s operations features on the Enterprise side of the platform. See pricing.
Starting small
You don’t need a full routing design on day one. A minimal setup that works:
- One role per team that does distinct work — office, field, dispatch.
- One queue-producing directive on the stage where human judgment is genuinely needed.
- One notification rule for the event people currently find out about too late.
Run that for a few weeks. The gaps will tell you what to add next, and they’re usually different from what you’d have guessed in advance.
The principle underneath
Both features express the same idea that runs through Atlas’s security model: responsibility belongs to teams. It’s the same reason topics are owned by user groups — see Why every topic needs an owner.
