Acumatica Case Screen — A Deep Dive

Cases (CR306000) is Acumatica CRM's support-ticket screen, built on the CaseMaint graph over the CRCase DAC. Its behavior is driven almost entirely by Case Class configuration rather than the screen itself — severity levels, SLA timers, and automation rules are all defined per class, and a case's class is typically fixed at creation, similar to how CustomerClass locks in defaults for a Customer.

Case class drives everything

Severity, initial response time, and resolution time targets come from the Case Class assigned when the case is created (Support Center Automation, under CRM configuration). Those SLA timers are what actually calculate the "due" fields visible on the screen — a customization that needs different escalation behavior for different types of issues should extend the case class model, not hardcode date math inside a graph extension.

Key tabs

• Details — customer/contact, severity, status, and the SLA countdown fields.
• Activities — the linked emails, tasks, and phone calls that make up the case's history; this is a shared CRM structure, not case-specific.
• Related Cases — parent/child linkage for cases that split or duplicate.
• Entitlements — appears when the case is tied to a support contract, showing remaining hours or incidents available.

Extending CaseMaint

A common request is auto-classifying inbound cases (from an email-to-case integration, for instance) based on keywords or the originating product, setting Case Class programmatically before the case is saved rather than relying on the agent to pick it manually. Another is enforcing that a case can't be closed without a resolution note populated — a straightforward RowPersisting check against the status transition.

public class CaseMaint_Extension : PXGraphExtension<CaseMaint>
{
    protected virtual void CRCase_RowPersisting(PXCache cache, PXRowPersistingEventArgs e)
    {
        var row = (CRCase)e.Row;
        if (row?.ClosedDate == null && row?.Status == "C" && string.IsNullOrEmpty(row.Resolution))
            throw new PXSetPropertyException("A resolution note is required before closing a case.");
    }
}

Custom fields and tabs via the Customization Project Editor

Adding a field to Details (a product version, an internal severity override) is standard. A new tab is common here too — a "Root Cause Analysis" tab for a formal post-incident process, for instance — implemented as a related DAC keyed on CaseCD with its own PXTab, since that kind of structured follow-up rarely fits as a handful of fields on the main tab.

Common validation and event-handler use cases

Beyond auto-classification and close validation: escalating a case's severity automatically when its SLA due date is breached (via a scheduled processing screen or a business event watching the due-date field), restricting which contacts can be linked to a case based on active contract status, and syncing case status changes to an external ticketing system through a custom subscriber.

Gotchas

SLA timers pause and resume based on status transitions configured per Case Class — a customization that reads the due-date field directly without accounting for paused time will calculate breach incorrectly. Entitlement consumption (hours or incidents against a contract) is decremented at specific status transitions, not continuously, so a case sitting "in progress" for a long time doesn't necessarily reflect ongoing entitlement usage the way a naive report might assume. And converting or linking a Case to an Opportunity or a new Sales Order is a distinct, limited integration point — it's not a generic "case becomes any other CRM record" mechanism, and building on the assumption that it is leads to disappointment.

Wrapping up

Cases looks like a simple ticket screen but its real configuration surface is the Case Class, not the screen layout. Customizations that respect SLA pause/resume semantics and entitlement timing hold up; ones that reimplement escalation logic from scratch tend to drift from what the built-in SLA engine already tracks.