Running Workflows: A Worker's Guide

A workflow is a step-by-step guide your manager published. A run is you actually doing it, once. OpsBrain walks you through each step, saves everything as you go, and keeps a record your manager can review later.

Three things to know from day one:

• Progress saves automatically. You can pause anytime and pick up where you left off.
• You never need to remember what you did. Every answer, photo, note, and skip is logged for you.
• If something is wrong with the workflow itself, you can flag it or skip with a reason. That feedback goes straight to your manager and genuinely improves the SOP.

Open Workflows in the navigation. As a worker you see the page My workflows: workflows assigned to teams you belong to. You can search by name or team, and filter by category, team, or status.

If the page is empty, nothing is assigned to your teams yet. The empty state says it plainly: "When your manager assigns a workflow to one of your teams, it'll appear here." Ask your manager to assign one.

1. 1Open the workflow from My workflows.
2. 2Click Start Run.
3. 3Review the Start run window. It shows the workflow's Category, Status, Assigned teams, Estimated duration, and Total steps, plus an Important Notes list: progress is saved automatically, you can pause and resume anytime, and some steps may require uploads or confirmations.
4. 4Confirm to begin, or pick View Guide instead if you just want to read the steps without starting.

Why starting can be blocked

Sometimes the run will not start. Here is what each message means:

Open Active Runs in the navigation for a live view of runs in motion. There are two tabs: All runs and Queue.

The All runs table shows Workflow, Worker, Current step, Elapsed, and Status, ten runs per page. You can search by workflow or worker, and filter by Workflow, Worker, or Status. Click View run on any row to open it.

What the statuses mean

The Queue tab holds runs that are waiting for someone on your team to take them. They arrive from connected systems (a customer order, a support ticket) or as handoffs from another team's run. When the queue is empty you will see The queue is clear.

Three tiles summarize the state of the queue: Awaiting claim, Escalated, and Longest wait.

Reading a queue card

• Priority chip: Low, Normal, High, or Critical. Critical pulses so it is hard to miss. The queue is sorted by priority first (critical at the top), then oldest first within the same priority.
• Source chip: External (or the name of the connected system that created it) or Handoff from another run.
• Wait time: how long it has been sitting, shown as "Waiting…" with minutes, hours, or days ("under 1m" when it just arrived).
• Escalated badge: the run has waited past its deadline. OpsBrain checks every minute and marks overdue runs. An escalated run is still claimable; the badge just means it needs attention now.

Claiming a run

Click Claim run (or View run first if you want to look before committing; a handed-off run's page offers Claim & start). Claiming makes the run yours: it moves to In Progress under your name, and your working clock starts at the moment you claim, not when the run was created, so wait time in the queue never counts against you.

If claiming fails with "This run isn't available for pickup.", someone else got there first. If you see "Your team can't pick up this workflow.", the run belongs to a different team's queue.

Giving a run back

Claimed something you cannot finish? Open the run and click Return to queue. The dialog Return this run to the queue? explains: your claim is removed and the run goes back to the team queue, where anyone eligible can take it. Confirm with Return to queue or choose Keep working on it. You will see "The run is back in the team queue." when it is done. Managers can also use Reassign to hand a run directly to a teammate.

Once a run starts you are in the player. Across the top: a pulsing Live run pill, the workflow's name, a live elapsed timer, and a progress bar counting steps complete. Two buttons live up there too: Pause and Exit run. They do very different things, see section 10.

The step card

Each step shows a Step … of … pill, a red Required marker when the step is required, the step title, the instructions, and then whatever input the step needs. At the bottom: Add note, Flag issue, and a skip button. The main button is Confirm on confirmation steps and Save & continue otherwise; on required steps it stays disabled until you have answered.

What each step type asks of you

On decision steps, a dashed panel below the buttons previews where each answer leads when it matters, for example "Yes → Damage Flow", with an ends here chip when that answer hands the run off. Answers that simply continue to the next step are not called out.

Prefilled answers from connected systems

When a run was started by a connected system (an order system, a ticketing tool), some text, number, and date fields may arrive already filled in. A violet From … chip above the field tells you where the value came from. There are three flavors:

Upload steps show a dropzone reading Upload a photo or Upload a file, along with the requirements: Required: at least …. and, for file steps, an "Accepted:" list of file types (for example PDF, DOCX).

• Click Choose photo or Choose file to add the first one; the button becomes Add another photo / Add another file after that.
• A counter tracks progress ("… uploaded", "of … required") and a green Ready chip appears once you have met the minimum.
• Photos show as a thumbnail grid; files show as rows with their size and a remove button.
• Uploads happen immediately as you add them, not when you press continue. If you pause the run, everything you uploaded is still there when you come back.

Leaving a note

Click Add note on a step to open the Note to managers panel and add context about this step; managers see it in the audit. Click Hide note to tuck the panel away. Use notes for anything a manager should know: a workaround you used, a detail the instructions missed, a suggestion.

Flagging an issue

When something is genuinely wrong, click Flag issue. The Flag an issue window flags the step for a manager to review:

1. 1Pick an Issue type: General, Unclear instructions, Equipment issue, Missing resource, Policy conflict, or System error.
2. 2Describe it in What happened?. Be specific enough that a manager can act on it.
3. 3Click Raise flag. You will see "Issue flagged. A manager will follow up shortly."

Flagging does not stop your run. You can keep working, skip the step if it is blocked, or pause. Managers resolve flags on their side and the resolution is tracked.

The skip button at the bottom of the step card comes in two forms, and they behave differently.

Optional steps: Skip

The dialog Skip this step? confirms that optional steps can be skipped, and offers a Reason (optional) field ("Anything you want your manager to know?"). Add a reason if it would help your manager improve the workflow, then click Skip step.

Required steps: Skip with reason

Required steps can still be skipped when they are genuinely blocking you, but you must say why. The dialog Skip a required step? explains that your reason goes to your manager's optimization inbox so the SOP can be fixed. The Reason (required) field must be filled before the red Skip anyway button unlocks. A good reason looks like the placeholder example: "e.g., This system was already updated by the previous shift".

The two buttons in the header do opposite things, so it is worth being sure:

To pick a paused run back up, open it and click Resume run (or Continue run). You land exactly where you left off, progress preserved.

Some decision steps launch a different workflow that belongs to another team. When that happens mid-run:

• A new run of that workflow is created as Pending pickup and lands in the other team's Queue. Everyone on that team is notified that a run is waiting to be claimed.
• Your own run either waits (Waiting for sub-flow) so you can continue after their part is done, or ends as Handed off when the workflow was built to fully pass the baton.
• On the receiving side, a teammate claims it with Claim run or Claim & start, and their clock starts when they do.

Connected runs stay linked. The run page shows the relationships: Parent run, Sub-flow of, Handed off from, and Spawned runs, including which step launched what and who was working it. You can always trace how a piece of work arrived at your desk.

The completion screen

After the last step, OpsBrain congratulates you with one of its rotating headlines, such as Nicely done., That's a wrap., Run complete., or Great work., and confirms that every step is done and logged. You get two stats, Total time and Steps completed, and a Back to Workflows button. That is it. Nothing else to file.

The audit trail

Managers can open any run and see a Step-by-step audit trail: every step you touched, with values, notes, flags, and attachments. For each step that means the submitted value, your worker note, any skip (including force-skips of required steps with the reason you gave), attachments with counts, and flag resolution state. Steps are labeled Completed, Skipped, In progress, Pending, or Skipped by branch (steps your path never visited). The run header shows overall progress, steps completed, flags raised, and duration.