A support case in Acumatica is a state machine wearing a form. The Case screen (CR306000) looks like a data-entry screen, but the value is in the lifecycle behind it: how a case moves from New to Closed, which SLA clock is running, when it escalates, and how billable time turns into an invoice. Get the lifecycle configured properly and the Service Management module runs support as a tracked process instead of an inbox.
The anatomy of a case
A case belongs to a customer (or a contact), sits in a case class, and carries a status, a severity, and a reason. The case class is the most important choice you make — it drives the default SLA, whether the case is billable, the workflow it follows, and the assignment map. Two customers with different contracts should sit in different case classes so their cases inherit different behaviour without anyone remembering to set it by hand.
Almost everything that makes cases behave — SLA duration, billing, the activities that count toward resolution — is set on the case class, not on the individual case. When someone asks "why isn't this case billing", the answer is nearly always in the class, not the record.
The status flow
Out of the box a case moves through a small set of statuses, and each transition means something to the SLA and to reporting. The typical path is New → Open → (Pending Customer) → Resolved → Closed, with the SLA clock pausing while you are waiting on the customer and resuming when the ball is back in your court.
New -> case created, SLA clock starts, awaiting first response
Open -> assigned and being worked
Pending -> waiting on customer; SLA clock paused
Resolved -> fix delivered, awaiting customer confirmation
Closed -> confirmed; case is read-only, time is billableThe distinction that matters for SLA reporting is who you are waiting on. Time spent in a Pending-Customer status should not count against your response or resolution SLA — that is the customer's clock, not yours. Configure the pending statuses so the SLA calculation excludes them, or your first-response metrics will look terrible for reasons outside your team's control.
SLA and escalation
The SLA is defined against the case class and, in Service Management, against the service contract or severity. It sets a target for first response and for resolution. Escalation is what happens when that target is at risk: the case bumps to a higher escalation level, reassigns to a lead or a group, and (if you wire it up) fires a business event to notify someone. The mechanics come from the schedule and the business-event engine, not from a person watching a queue.
SLA and escalation timing respect the working-hours calendar. If the calendar is wrong — no holidays, wrong time zone, a 24/7 calendar on a 9-to-5 team — every SLA will be miscalculated and cases will escalate at 2 AM local time. Set the calendar up before you trust a single SLA number.
Assignment and ownership
Assignment maps route a new case to the right owner or workgroup based on the case class, customer, or attributes. The alternative — manual triage — is where cases go to die, because nobody owns "unassigned". Use an assignment map to give every incoming case an owner at creation, and use workgroups rather than named individuals so a case is still owned when someone is on leave.
Turning case work into a bill
The reason Service Management sits close to the financials is billing. Time and activities logged against a billable case class accumulate on the case, and when the case is closed those billable lines flow into an AR invoice through the case's billing setup. The two levers are whether the case class is billable at all, and whether each logged activity is marked billable — a non-billable activity on a billable case simply does not bill.
| Lever | Where it lives | Effect |
|---|---|---|
| Billable case class | Case class setup | Enables billing for cases in the class |
| Billable activity | The activity / time entry | Decides whether that line reaches the invoice |
| Rate / labor item | Employee / contract | Sets the amount per billable hour |
| Contract coverage | Service contract | Can zero-out billing under a prepaid plan |
Reporting the lifecycle
Because every transition is timestamped, the case history is a clean dataset: time-to-first-response, time-to-resolution, SLA breach rate, and reopen rate all fall out of the status changes. The one thing to watch is that generic inquiries and dashboards must exclude the paused (pending-customer) time to be meaningful — the same correction that makes the SLA fair makes the reports honest.
Wrapping up
Treat the Case screen as the surface of a state machine and the module does its job: cases enter with an owner and an SLA, pause the clock while they wait on the customer, escalate before they breach, and turn billable work into an invoice on close. The configuration all lives on the case class and the SLA schedule — get those right and the day-to-day is just moving cases through a flow that already knows what to do. If you are wiring up a specific SLA or billing rule, reach out or keep reading through the rest of the Acumatica blog.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.