A process instead of a status field. How Opero moves a case through stages

In many companies the stage of a case is just a field value: a “Status” column in a spreadsheet or a picklist in a system. Anyone with access to the record can change it, and the system records at most that the value has changed. People are left to remember the order of steps, who may move the case forward and when things are due.

That works while cases are simple and handled by a few people. At the first dispute it turns out that nobody can say who approved the cost, and the invoice reached payment before anyone described it.

Stages and transitions

In Opero a process is defined as stages and the transitions between them. The process is attached to the object the company already works on: a request, an order, a contract or an invoice. A record moves from stage to stage only along transitions defined in the process design. A transition that is not in the design cannot be performed, regardless of who has access to the record.

Example: a cost invoice workflow

The cost invoice workflow in the demo organisation looks like this:

1. “Registration” is the start stage. Its only transition is “Send for description”.

2. “Business description” has a three-day deadline. It leads on through “Send for approval”.

3. “Approval” also has a three-day deadline. Three transitions leave it: “Approve cost”, “Return for completion” and “Reject”.

4. From “To be paid” the transition “Mark as paid” closes the case in the final stage “Paid”. Rejection leads to the second final stage, “Rejected”.

What matters most is what the diagram does not contain. There is no transition from registration to payment, so an invoice cannot reach “To be paid” without being described and approved. A return for completion sends it back to the business description instead of leaving it in limbo.

Permissions and conditions on transitions

Each transition defines who may perform it and under what condition. The cost is approved by a person authorised to approve it, not by everyone who can see the invoice. Responsibility is attached to a step in the process, not to whoever happened to have access to the record.

Tasks and deadlines

Entering a stage creates a task assigned to a specific person, with the option to redirect it when that person is away. Tasks appear on “my tasks” lists and on kanban boards, so a case does not sit in the inbox of someone who does not know it is waiting. The stage deadline, three days for the description and three for the approval in this example, is part of the process design rather than an arrangement people have to be reminded of.

Different forms at different stages

At each stage you decide what the user sees and what they can change. The person describing the cost fills in the project, department and account, while the approver sees that data read-only and makes the decision. Nobody at the approval stage can change the description they are meant to approve.

The history of the run

Every transition stays in the case history: who performed it, from which stage and when. The run can be traced step by step, which matters in an inspection, an audit or a dispute with a counterparty. We cover what a case history should contain in “Case history: what you should be able to reconstruct a year later”.

What a process will not decide for you

A process design requires decisions the system will not make for the company. If it is not settled who approves costs and above what amount a second approval is needed, the process will only expose that gap sooner. Work on a workflow therefore starts with agreeing roles and responsibilities, and only then with designing the stages.

Changing the process

Changing the process design, for example adding a stage or a new transition, does not require a developer. Who in the company should be allowed to do it is a separate question, covered in “Who in the company should be able to change a process in the system”.

Where to start

With one workflow where the question “who approved this” comes up most often. In most companies that is the cost invoice or the contract. One well-designed process shows its value sooner than rolling out a whole catalogue of workflows at once.