A case is a promise to a customer. Most of the work required to keep that promise happens somewhere else — in a task for the field team, an incident for the platform team, a problem record for engineering, a change for the next release. How you connect the promise to the work is the third foundational decision in a Customer Service Management build, after foundation data and the case lifecycle itself.
Get it wrong and you get double bookkeeping: two records tracking one piece of work, kept in sync by an integration nobody trusts, with a customer-facing state field that lies.
The one rule everything else follows
The case never leaves the customer service agent.
Whatever spawns downstream, the case stays owned by the person accountable to the customer. Downstream records are how other teams contribute; they are not a way to hand off responsibility for the relationship. Every ugly CSM implementation I have unpicked violated this rule somewhere — usually by reassigning the case to an engineering group, at which point the customer stopped hearing anything because engineers do not write customer updates and were never asked to.
Hold that rule and the rest of the decisions get much easier.
Choosing the right downstream record
| Situation | Record | Why |
|---|---|---|
| Discrete work by another team, specific to this customer | Case task | Stays inside the case’s lifecycle; the case owner still drives |
| A service is degraded or down and IT must restore it | Incident | ITSM owns restoration; many cases can point at one incident |
| Repeated cases share an unknown root cause | Problem | Root cause work outlives every individual case |
| A fix requires a production change | Change request | Change control belongs to the change process, not the case |
| Physical goods must move | Return / order case | Purpose-built lifecycle with fulfilment states |
The distinction that trips people up is case task versus incident, so it is worth stating plainly.
A case task is work that only matters because of this case. Ship a replacement part. Have a specialist review a configuration. Get legal sign-off on a credit. Nobody outside this case cares that the task exists, and when the case closes, the task is meaningless. Case tasks are cheap, they carry their own assignment and state, and they do not require any integration to work.
An incident is a degradation of a service that would need fixing whether or not this customer had called. It has a life independent of the case. Crucially, the relationship is many cases to one incident — if forty customers report the same outage, you have forty cases and one incident, and any design that produces forty incidents is wrong.
That asymmetry is the tell. If you find yourself creating exactly one incident per case, you are not integrating with ITSM; you are copying your case table into a second table and signing up to keep them in sync forever. Use a case task instead.
Problems and changes follow the same logic one level further out. A problem exists because the same fault keeps generating cases — it is created from the pattern, not from any single case. A change exists because a fix needs to go through change control. Neither should ever be created reflexively per case.
State synchronisation, and how to keep it small
Once a case points at an incident, two records have states and someone has to decide how they relate. This is where implementations acquire their most fragile code.
The design that holds up over time is deliberately asymmetric:
Downstream progress flows up as information, not as control. When the incident is resolved, the case should learn about it — a note, a flag, a notification to the case owner. It should not automatically resolve the case. Restoring a service and satisfying a customer are different events; the second one requires someone to check the first actually helped and to tell the customer so.
The case does not push its state down. A customer going quiet on a case has no bearing on whether the platform team should stop working an incident. Coupling in that direction produces genuinely strange behaviour, like closing a case cancelling work that fifteen other customers are waiting on.
Sync a minimum of fields. State, resolution notes, and a link are usually enough. Every additional synced field is a new way for the two records to disagree, and the more fields you sync, the more the integration looks like an argument between two systems about who owns the truth. The same discipline that keeps a data access layer from leaking vendor specifics into business logic applies here: define the narrow contract between the two domains and refuse to widen it because one report would be marginally easier.
Out of the box, the CSM–ITSM integration already implements most of this. The temptation to “improve” it with additional bidirectional rules is strong and should mostly be resisted. Custom sync logic is the single most common source of long-running defects I see in mature CSM instances, precisely because it fails quietly — nobody notices a state that stopped propagating until a customer asks why their case says “in progress” three weeks after the fix shipped.
The SLA question nobody asks early enough
While an incident is being worked, is the case SLA running?
There is no universally right answer, but there is a universally wrong one: not deciding, and discovering the answer months later during a contractual dispute.
If your commitment to the customer is about response, the clock should generally keep running — the customer is still waiting, and “we are blocked on another team” is your problem, not theirs. If the commitment is about resolution and the case is genuinely blocked on a dependency the customer caused or controls, a pause is defensible.
Whatever you choose, encode it in the SLA definition’s pause conditions rather than in scripts, make it visible to agents on the case form, and make sure your service managers can explain it. An SLA nobody can explain is an SLA you will end up honouring on demand regardless of what the data says.
Practical guardrails
A few rules that consistently prevent trouble:
- Never let a downstream record be the only place customer-visible information lives. If the resolution explanation exists only on the incident, the customer never sees it and the next agent to touch the account cannot find it.
- Case tasks should have their own SLAs if other teams own them. Otherwise “the field team will get to it” absorbs the whole case SLA silently.
- Make the many-to-one relationship visible. An agent looking at an incident should see all the cases attached to it, because that count is what tells a manager how big the customer impact actually is.
- Do not create downstream records automatically from case creation. Automation here feels efficient and produces a permanent pile of empty incidents nobody closes. A human decides when work leaves the case.
Where the effort actually goes
Teams building this out expect the hard part to be the technical connection between CSM and ITSM. It rarely is — the platform ships that. The hard part is the organisational agreement: which team owns what, when the case owner is allowed to chase, and what the customer is told while another team works the fix.
That agreement is the deliverable. The configuration is downstream of it — which is why this work sits closer to architecture and process design than to platform administration, and why our ServiceNow practice usually starts by mapping who owns which record rather than by opening a form designer.
That is the end of this CSM series — foundation data, lifecycle, and downstream work. If you have an instance where cases and incidents have quietly drifted into a one-to-one mirror and the sync logic has become load-bearing, that is a conversation worth having before the next round of changes.