The case lifecycle

A case is xMatix's record of one customer issue, from first contact to close. Cases live in the CRM app under Cases (default view All Cases). Every case carries a case number, a subject and description, classification fields (case source, case type, case reason, category, subcategory, priority, severity, customer tier), links to the account, contact, asset and product involved, and a lifecycle Status. The status is what you move; the platform reacts to each move by stamping dates, starting or pausing SLA clocks and writing timeline entries, and it refuses moves that lack the information they need.

Read the screen

12345 Expand

1. 1

   Name is required on the form; the formal Case Number is generated from document numbering when the case is saved.

2. 2

   Account (and Asset on the row below) locate the customer relationship and the equipment affected; Customer Tier carries commercial importance.

3. 3

   Subject and Description state the observable problem and the outcome the customer needs — write them so someone who did not take the call can act.

4. 4

   Case Source, Case Type, Case Reason and Category classify the issue; SLA policy match formulas can read any of them the moment the case is saved.

5. 5

   Priority is how fast the business should act; Severity is how serious the impact is — keep them distinct because routing and SLA policies may match on either.

The create form (New on the case list) captures the facts every later decision inherits. Account and Asset locate the customer relationship and the equipment affected; Subject and Description state what is observable and what outcome is needed; Customer Tier carries commercial importance. The Basic Details tab holds the classification — Case Source, Case Type, Case Reason, Category, Priority and Severity. These are operational inputs: the SLA policy that attaches on save can match on any of them, and queue routing reads them too. Keep Priority (how fast the business should act) distinct from Severity (how serious the impact is). The picklist values are tenant-maintained, so the options you see may differ from another tenant's.

12345 Expand

1. 1

   Priority, Severity, Assigned To and Status in the header; Assigned To is the working owner, distinct from the record Owner.

2. 2

   The stepper is the tenant's Status picklist — this tenant has no Waiting or Escalated steps, which the handler would still honour if added.

3. 3

   A breached resolution SLA surfaces as a banner on the record; the milestone detail is on the SLA tab.

4. 4

   Overview, People & Queue, SLA, Resolution and Duplicates each answer one lifecycle question; Resolution holds the summary and close reason the terminal states require.

5. 5

   Status changes and reassignments are written to the timeline as completed system entries — 'Status changed from Assigned to New' here — so history never has to be reconstructed.

The saved record is where the lifecycle is read. The header shows the case number, partner account, branch, account, Priority, Severity, Assigned To and Status; the stepper beneath it walks the Status picklist and marks the current state. Overview groups the classification (Key Information), the subject and description (Case Details) and the audit fields (System Information). People & Queue holds the account and contact plus the assignment context (assigned to, queue, partner account, branch, resource); SLA shows the attached policy, milestones and SLA events; Resolution holds the resolution summary and close reason; Duplicates lists likely duplicate cases; Knowledge, Call Register, Attachments and Related complete the tabs. The Activities panel on the right is the timeline — every status change and reassignment is written there as a completed system entry, so the record explains its own history.

What happens when a case is created

One save does all of the following before anyone touches the case:

• Identity and timestamps. The case number is generated from your document numbering settings (the shipped series is CS followed by the date and a six-digit sequence), the status defaults to New, and the Date/Time Opened and Document Date are stamped with the current time.
• SLA attachment. Active SLA policies are considered in rank order (highest rank first, then the default policy); the first whose match formula is empty or evaluates true for this case attaches. Its first-response and resolution milestones are created with due times computed in the policy's business hours, the SLA Status becomes OnTrack, and an Applied SLA event is recorded. If no policy matches, the case simply has no SLA.
• Acknowledgement. An email activity named Case acknowledgement is written to the timeline. With a Contact Email it is recorded as Sent and the message — subject We've received your case: {subject}, quoting the case number — is dispatched after the save completes, so a slow or unreachable mail host never delays creation; with no address it is recorded as Draft. The activity status is not delivery confirmation.

The Closed When Created switch logs an issue you already resolved on the spot: the case is created directly in Closed with the closed time stamped. It still needs a Close Reason, exactly like any other close.

The operational states

These eleven values are the ones the case handler gives lifecycle behaviour. The Status picklist itself is tenant metadata: a tenant may lack some of them (the stepper in the screenshot has no Waiting or Escalated steps) or carry legacy values such as Draft or Working, which gain none of the stamps above.

Which pause states stop the clock is configurable per SLA policy (Pause Statuses); when a policy leaves it blank, On Hold, Waiting on Customer and Waiting on Third Party pause. Moving back to an active state resumes the clocks and pushes each paused milestone's target forward by the business time spent paused, so a legitimate wait never counts against the team.

Two moves carry hard field requirements: Resolved is rejected with A resolution summary is required to resolve a case. and Closed with A close reason is required to close a case. The Close action in the header asks for the reason (and optionally a resolution summary) and performs the move for you. Reopen is accepted only from Resolved, Closed or Cancelled — otherwise Only resolved, closed or cancelled cases can be reopened. — and clears the closed and resolution dates so the SLA picture reflects that work restarted. Escalate sets the status and the flag in one step and can hand the case to a named agent at the same time; a case whose SLA rolls up to Breached is flagged escalated automatically.

Which transitions are allowed

The shipped restrictions are business rules named Case: block transition from …, one per source status, each rejecting the save with This case can't move from {status} to that status. Your administrator can loosen or tighten them. The defaults:

Owner versus Assigned To

A case has two people fields with different jobs. Owner is the record owner in the platform's security sense — whose record it is. Assigned To is the working owner — who is handling it now. They are often the same person. Omni-channel routing does not change either field when it offers work from a queue; the moment an agent accepts the offer, both Assigned To and Owner are set to that agent's user. The Route action needs a queue: it uses the case's Queue, or a queue or resource passed with the action, and otherwise stops with Routing requires the case's QueueId, or a queueId/resourceId argument.

How history is recorded

Every update that changes the status writes a completed timeline activity — Status changed from {old} to {new} (or Status set to {new} when there was no previous value) — and every change of Assigned To writes Assigned to {user id}; both carry the time of the save. SLA events (Applied, Warning, Breached, Paused, Resumed, Met, Cancelled) are a separate stream on the SLA tab, and the manual Pause SLA / Resume SLA actions add SLA clock paused / SLA clock resumed events there. Field-level edits are in the record's audit trail.

Duplicates and conversions

Find Duplicates (the Duplicates tab) lists up to 25 open, unmerged cases that share this case's contact, account or phone number, newest first, each labelled Same contact, Same account or Same phone. Compare & merge lets you choose which values survive; the other case's activities, attachments and people move to the survivor and the duplicate is closed with close reason Duplicate, keeps its own case number and points at the surviving case. See Collaborating on cases.

Convert to Lead and Convert to Opportunity (header buttons Lead and Opportunity) create a linked record pre-filled with the case's account, contact, branch and partner account (the opportunity also takes the asset and the case's resource as service advisor). Neither changes the case status, and neither is limited to one conversion per case. The header also offers Appointment (books a demo or appointment) and, where enabled, Generate Service Order for issues that need workshop time.

Common questions

Why won't the case let me resolve or close it?

Because the explaining field is empty: Resolved needs a Resolution Summary and Closed a Close Reason, and the error names the missing field. If both are filled and the move is still blocked, the Case: block transition from … rule for the current status forbids that jump; ask your administrator which rule fired.

The Assigned To field shows an identifier rather than a name — is the case broken?

No. The value is the working owner's user id; the assignment is recorded and routing, ownership and the timeline entry all work from it. The display resolves to a name where the tenant's user lookup is configured for it.

Can I edit the case number or the opened time?

No — both are stamped at creation. The case number comes from document numbering and stays stable for the life of the case, including through merges, where a duplicate keeps its own number and links to the surviving case. The opened time is the SLA clock start, which is also why a case created from a lead does not inherit the lead's dates.

Related topics

• SLA policies and milestones
• Queues and omni-channel routing
• Collaborating on cases
• Escalating a case
• Business rules
• Case — entity reference