Beyond the Status Field: Why We Built a Real Workflow Engine for Kribik

The Problem with "Status"

We’ve all suffered through the slow-motion disaster of hard-coding ourselves into a maze of status IDs. Traditional ticketing systems worship the almighty “Status” dropdown as the primary signal of progress, and it works right up until reality shows up. Status is a leaky abstraction: fine for a personal to-do list, useless once approvals, dependencies, and risk enter the room. In serious operations, static, hard-coded states don’t just limit you... they actively work against you. Treating complex work as a single frozen label is how tickets get stuck, teams improvise, and process quietly falls apart.

That said, we did not rip it out. In Kribik, Status is still the default because sometimes you just want something quick, familiar, and lightweight. Not every team needs governance. Not every ticket needs ceremony. Workflows are optional and configurable per organisation, so teams can adopt them only where they add real value.

The problem starts when a process is reduced to a fixed list of labels. Tickets inevitably get stuck, and your only way out is a series of manual workarounds. At Findon Software, we realised that to support ITIL-aligned service management properly, we had to stop treating work as a state and start treating it as a flow.

Why Table-Driven Workflows Matter
The core architectural shift in Kribik is the move to a table-driven workflow engine. Instead of forcing every team into one universal set of statuses, workflows let each organisation define the states and transitions that match how they actually operate. You can keep Status for the simple stuff, and switch on workflows for the areas where control, traceability, and approvals matter.

Approvals Should Never Be "Bolted On"
Most tools treat approvals as a UI decoration, a notification or a checkbox that doesn’t actually control anything. In Kribik, approvals are a core engine component. We followed the ITIL litmus test: if someone doesn’t have the specific power to stop a change, they shouldn’t be an approver. If they are just there to be informed, that’s a notification, not an approval gate.

Our engine treats transitions as approval-gated. A ticket cannot move to the next state until the criteria are satisfied. To make this robust enough for real operations, we implemented:
• Multi-step chains: Sequential gates that must be cleared in order.
• Per-step requirements: Specific users or roles, with a MinApprovals threshold for each step.
• Hardened security: We don’t rely on hidden buttons. We validate eligibility server-side, and forged POST requests are rejected. The engine checks both organisation and ticket ownership before any approval is recorded.

In a "Normal Change" scenario, this means a technical lead can sign off on technical risk, and a service owner can approve the business case, before anything moves into implementation.

The Power of Centralised Logic
To avoid the scattered logic problem where different intake paths (UI, sub-tickets, or email ingestion) behave differently, we centralised workflow bootstrapping. This service is designed to be idempotent. In our world, that’s a requirement, not a feature. It means if a process retries or a handler runs twice, you don’t end up with duplicate approvals or corrupted state.

The engine uses typed JSON schemas to handle complex logic without requiring code changes:
• Conditions: Logical composition using and, or, and not. Transitions can depend on actor rules or ticket attributes like assignment or due dates.
• Actions: After a successful transition, the engine can update ticket fields, assign users, or modify labels.

Keeping this schema-driven and validated makes it safer to extend, and more predictable under load.

Building for Compliance Without Breaking the Present
Architecting a platform update of this scale requires respect for how people already work. That’s why workflows in Kribik are opt-in. Existing teams can stay with Status if that’s what fits. Teams that need stronger control can enable workflows and introduce approvals gradually, without breaking their current operations.

For organisations following ITIL or PRINCE2, this lays the groundwork for compliance-grade audit trails. The workflow engine is the natural central point for capturing:
• Transition attempts and final applications.
• Approval requests and decisions (approved vs. rejected).

That approach meets Change Advisory Board expectations at the architectural level, rather than relying on fragile UI logs.

What This Architecture Unlocks
We are moving from "tickets with statuses" to a platform where process is configurable, enforceable, and visible. Status stays as the simple default. Workflows are there when you need something stronger.

By shifting control into a table-driven engine with real approval gates and centralised services, we’ve cleared the path for automated escalations, granular SLA tracking, and release management that reflects how work actually flows. It’s a tool built for people who understand that in operations, the process is the product.