Skip to content
omercelik.dev
Get in touch
All work

Telco · Client · 2025 — now

Part of Replacing a telco's order management while it keeps taking orders

One process per order, and the people in it

Each product order runs as its own workflow: downstream systems answer late, people step in at hundreds of points, and an order can still be cancelled while it runs.

Context

A business order touches network inventory, work orders, billing and people who confirm technical details. Some of those systems answer days later. Every order needs its own state, has to survive slow downstream systems, and needs a clear answer to "can this still be cancelled?".

Try it: step an order through its process, then cancel it before and after the milestone.

DemoWorkflow stepper

Step one product order through its process, watch the events it emits, and try to cancel it midway.

How it works

  • One workflow per product order. A submitted quote is split into product orders, and each runs as its own Camunda 8 process. A table decides which process a product order runs; the splitting itself is a small strategy per scenario, so each new scenario stays isolated.
  • The business logic stays in .NET. The process calls back into the services to create service orders and update the order, so the process model only describes the flow.
  • Late answers find their order. Every outbound request carries a message id. When a downstream system calls back, the answer is matched to the waiting process by that id, however late it comes.
  • Change is allowed up to a milestone. The process marks the point after which cancelling or changing isn't safe anymore. Before it, the request is applied to the running order. After it, the request is refused with a reason.

The people in the process

Across all order types, the processes stop at hundreds of points for a person: confirm technical details, pick equipment, approve a change. Building a screen for each one would have given us hundreds of forms drifting apart. So every user task goes through one pipeline.

Resolvehandler by order andtaskLoadfields from metadataFillcurrent valuesRendercomponent by typeSavechanged fields only

Every user task, one pipeline

Adding a task is mostly configuration, and a fix in the pipeline reaches every task at once.

My part

I built the Camunda 8 client layer the platform uses for processes, messages, user tasks, incidents and deployments, and the user task framework: the handler pipeline, the worklist, the task stepper and the form renderer. I led the team that built the process models, the scenarios and the task pool on top of them.