From a written process to one the system runs

Where written processes break down

Most organisations have a written process. An SOP, a quality manual, a laminated flowchart by the door. Everyone signed the training record; nobody runs it quite the same way. The forms get filled, but the steps around the forms live somewhere else. Who investigates this incident? Does a deviation need a quality assessment before anyone starts a corrective action? Who confirms the work order was actually done: the technician who closed it, or the person who raised it?

On paper, all of that is precise. In practice it's email threads, verbal hand-offs and "I thought you had it." The process is described in one place and performed in another, and the gap between the two is where records stall, skip a step, or get closed by someone who was never supposed to close them.

A workflow the system runs

In Tebelis the process is part of the template. Each template carries its own workflow: the states a record moves through (say reported → under investigation → corrective action → verified → closed for a safety incident), which transitions are allowed from each state, and who owns each step.

Because the workflow is part of the record, the system enforces it:

• Ownership is explicit. Each step is owned by named people, a group, or "whoever is named in the investigator field on this record." Only the step's owners (and workspace admins) can move the record on, so it's always clear whose turn it is.
• Hand-off is automatic. When a deviation is assessed and moves on to corrective action, the record lands in the next owner's tasks and they're notified.
• Earlier steps lock. Fields that belong to an earlier step lock once the record moves past it. A reviewer can't quietly rewrite what the person who reported the incident described, and what the technician entered on the work order is exactly what the requester signs off.
• Sending back needs a reason. Send a record back a step (a corrective action rejected at verification, a work order bounced at sign-off) and the system requires a comment by default. The reason stays in the record's history, next to the step it came back from.

Setting it up by describing it

You don't draw state machines. Tell the agent "add a verification step owned by the maintenance supervisor, and require a comment if anything is sent back for rework", or "a failed franchise audit escalates to the regional manager before re-inspection", and it drafts the states, the transitions, the owners and the rules. You review and publish. Later changes, such as a new approval, a different owner or an extra check, work the same way.

Changing the process later

When you publish a change to a template, it becomes a new version. Records already in progress keep the process they started under, and new records pick up the change. An investigation opened last month finishes under last month's rules; this week's records follow the new ones. You can tighten the process on a Tuesday without invalidating everything mid-flight on Monday.

The other posts cover setup, capture and analysis. The workflow is what carries each incident, deviation and work order from raised to closed, with a clear owner at every step.