Stop Writing RACI Tables. Start Running Them.

In the last post, we talked about why Kribik moved beyond the humble “Status” dropdown and into a proper workflow engine.

This time, let’s talk about the thing that quietly determines whether any workflow survives contact with reality.

Ownership.

Most organisations already have an ownership model. It lives in a spreadsheet, a wiki, or a process document that everyone agrees is “important” and nobody actually checks.

That model is RACI.

And if you’ve ever been in the middle of a change, an incident, or a handover and heard:

• Who is meant to approve this?
• Are we waiting on someone?
• Why did this move states without sign-off?
• Who should we have told?

…then you already know the problem.

RACI exists, but it isn’t wired in.

So we wired it in.

The problem with RACI as documentation

Traditional RACI tables describe how a process should work.

But tickets don’t get stuck because the process was described incorrectly. They get stuck because nothing enforces it.

When RACI lives outside the system:

• anyone can push a ticket forward (or forget to)
• approvals turn into polite suggestions
• stakeholders get spammed, or worse, never told
• accountability is sporadic, and not enforced

Kribik’s position is simple:

If RACI is true, it should change what the system allows.

RACI in Kribik is per workflow state

We didn’t implement RACI as another per-ticket field you have to maintain manually. That just creates more admin and goes stale immediately.

Instead, RACI is defined on each workflow state, as part of the workflow itself.

That means:

• RACI becomes a reusable governance template
• every ticket entering that state inherits the same ownership rules
• ownership is visible exactly where it matters

If “Change Assessment” is owned by technical roles and “CAB Review” is owned by governance roles, you define that once.

Then it holds.

Where RACI actually lives in the system

1) Workflow state editor: RACI as a control surface

In the Admin UI, every workflow state includes a RACI section where you assign organisation roles as Responsible, Accountable, Consulted, or Informed.

This isn’t there to decorate the page.

Those assignments decide two things:

• who is allowed to act while the ticket is in that state
• who is told what, and when

RACI here isn’t “extra process”. It’s the thing that stops process becoming theatre.

2) Workflow map: ownership plus “where are we?”

Kribik automatically diagrams workflows, and that turns out to be more than a nice picture.

The workflow map shows, at a glance:

• the current state
• the possible next transitions
• whether approvals are involved
• who owns the stage right now

Click a state and you see its RACI and outgoing transitions. The diagram is operational, not aspirational.

It’s the difference between “we have a process” and “we can see the process running”.

What RACI does in Kribik (not just what it says)

This is the key point: in Kribik, RACI has behavioural meaning.

Responsible: who can actually move work forward

In many tools, anyone with access can shove tickets through states. That’s how you get skipped steps and mysterious journeys to “Done”.

In Kribik, Responsible (and sometimes Accountable) acts as a gatekeeper.

If a workflow state has RACI defined and you’re not in an allowed role, you simply don’t get transitions to click. And crucially, the server enforces this as well.

Accountable: approvals that can stop things

Approvals are where most systems quietly give up.

They send notifications, record a tick in the activity feed, and then let the ticket move anyway.

Kribik takes a stricter view:

If a transition requires approval, the approval must have the power to block the change.

That maps directly to accountability in RACI. When a transition requires approval, only Accountable roles are eligible to approve it.

That’s how approvals stop being bolted-on ceremony.

Consulted and Informed: communication without chaos

RACI is also a communication model:

• Consulted are involved while the work is happening
• Informed are told about outcomes

In Kribik, those become notification rules tied to workflow states.

Instead of rebuilding “people to keep in the loop” lists on every ticket, communication is defined once, centrally, in the workflow.

The result:

• collaboration without chasing
• stakeholders get updates when it matters
• less notification noise caused by habit and guesswork

Routing rules: getting work into the right process

A workflow only helps if tickets land in the right one.

Routing rules in Kribik decide which workflow definition applies based on properties like:

• category and subcategory
• client
• priority

So different kinds of work automatically follow different processes from the moment the ticket exists.

For example:

• incidents route into rapid triage workflows
• changes route into approval-gated workflows
• specific clients route into contract-aware workflows
• high-priority tickets route into fast-lane variants

The pattern is simple:

Routing rules place work into the right process. RACI defines ownership and communication inside that process.

Versioning and audit trails that hold up in real life

Eventually, every serious workflow system gets asked:

What did the process look like when this decision was made?

Kribik treats workflows as operational assets.

Workflow definitions are versioned. Published workflows are stable. Changes create new versions instead of silently rewriting history.

On top of that, workflow activity generates audit events for:

• transitions being applied
• approvals being requested
• approvals being decided

So when someone asks “why did this move?”, the answer isn’t folklore.

What this unlocks next

Once ownership is explicit and enforced, a lot becomes possible without duct tape:

• automated escalation that knows who owns the stage
• SLA tracking that follows real process, not wishful timestamps
• reporting based on actual responsibility
• change management that behaves like change management

This is why workflows are a platform feature in Kribik.

In operations, process is the product.

Closing thought

If you use workflows without ownership, you’re just drawing diagrams.

If you use RACI without enforcement, you’re just writing documents.

Kribik’s goal is to make RACI run the workflow, so the system answers the questions teams usually have to improvise:

• Who can act?
• Who must approve?
• Who needs to be involved?
• Who should be told?
• Where are we right now?

That’s how you scale process without turning it into bureaucracy.

If you need help creating a workflow process, please send me a message.

You can play with the idea for free on https://kribik.com/