A form collects information. A pipeline decides what happens next. In Atlas, pipelines are part of Enginuity, the data and operations engine, and they automate processes like intake, review, verification and approval.
The pieces of a pipeline
Binding. A pipeline is bound to the resource it manages — for example, a record schema or a kind of topic. Each resource that enters the pipeline becomes a run you can track.
Stages. A pipeline moves through named stages, in order. Name them for your real process: Intake, Review, Verify, Approve.
Subroutines. Each stage runs three subroutines in a fixed order: PRE → PRIM → POST. PRE does setup work, PRIM does the main action, and POST handles follow-up. That predictable order is useful when a stage both waits on people and performs automated steps.
Directives. Each stage has a checklist of directives — the rows that must be satisfied to advance. Some are marked required. A stage only advances when every required directive is complete or skipped.
Mode. A pipeline runs FINITE, stopping when complete, or CONTINUOUS, re-running each cycle.
Building a pipeline
Atlas’s documentation describes four steps:
- Create a pipeline and bind it to the resource it manages.
- Add stages in order and name them for your real process.
- Add directives to each stage — the checklist rows that must be satisfied to advance — and mark some required.
- Choose FINITE or CONTINUOUS, then start it. Each resource becomes a run you can track.
Where people come in
When a directive needs human sign-off, the pipeline creates a queue entry scoped to a role — not to an individual. Anyone on that team can claim the work; until then it waits in the open queue. Completing the work satisfies the directive, and the pipeline advances the stage. See Work queues and notification rules.
FINITE or CONTINUOUS?
| Use FINITE when… | Use CONTINUOUS when… |
|---|---|
| The process has an end: a request is approved or rejected | The process repeats: a monthly check, a recurring inspection |
| Each resource goes through once | Each resource re-enters every cycle |
An example
A service request pipeline for Evergreen Landscaping might look like this:
- Intake — directives: contact details confirmed (required), photos attached (optional).
- Review — directive: office staff review the request (required; creates a queue entry for the office role).
- Schedule — directive: a visit date is set (required).
- Complete — directives: work summary recorded (required), customer notified.
Mode: FINITE — each request goes through once.
Why checklists, not just automation
Many workflow tools are either fully automated or fully manual. Checklist-gated stages sit in between: automated steps and human sign-offs live on the same checklist, and the stage can’t advance until the required ones are done. That makes the process visible — you can see exactly what a run is waiting on — and enforceable, because skipping a required step isn’t possible by accident.
APIs
Pipelines can also be driven programmatically: Atlas’s APIs let you start runs, satisfy directives and read run state, so your own applications can take part in the same process. See Atlas as the backend for your own applications.
Designing stages that match reality
The most common mistake in workflow design is inventing stages that nobody actually performs. A better approach:
- Describe the process out loud as someone who does the work would: “a request comes in, we check it, we book a visit, we do the work, we write it up.”
- Turn each phrase into a stage with a plain name: Intake, Review, Schedule, Complete.
- For each stage, list what must be true before it ends. Those are your directives.
- Mark the non-negotiable ones required. Everything else can be optional or skipped.
- Decide FINITE or CONTINUOUS.
If a stage has no directives, it probably isn’t a stage. If a stage has fifteen, it’s probably two.
Using PRE, PRIM and POST well
Each stage runs three subroutines in order — PRE, PRIM, POST. A practical way to use them:
- PRE: gather what the stage needs. Check that required information is present; prepare anything the main action depends on.
- PRIM: the main action — the human sign-off or the automated step the stage exists for.
- POST: follow-up. Record the outcome, notify people, and prepare the next stage.
That order is useful when a stage both waits on people and performs automated steps, because the automated parts can run before or after the human part predictably.
Pipelines and the rest of Atlas
- Records and topics. A pipeline is bound to the resource it manages, so it operates on the records and topics you’ve modeled.
- Work queues. Directives needing human sign-off create role-scoped queue entries.
- Notification rules. Events can notify the roles that should know.
- APIs. Runs can be started, advanced and read programmatically.
Frequently asked questions
Can a run go backwards? Pipelines advance through stages as directives are satisfied; if work needs redoing, design a stage that allows it, or handle it as a new run.
What happens if a required directive can’t be completed? The stage doesn’t advance, which is the point — the run visibly waits on what’s missing.
Can directives be skipped? A stage advances when every required directive is complete or skipped, so optional directives can be skipped.
How do I see what a run is waiting on? Each resource becomes a run you can track, showing its stage and checklist.
