Case controls & escalation

Timing, ownership, urgency, and workflow state change through explicit transitions, so moving work around a team never moves a borrower's deadline with it.

Case controls change when a case is next worked, who holds it, and how urgent it is — and none of them changes what the borrower owes or the deadline they are waiting on.

how work proceeds

A control moves

When it is next looked at — wait, snooze, scheduled contact
Who owns it — reassign, escalate
Whether the interval is open — reopen, close

what the borrower is owed

No control moves

A non-deferrable deadline
Whether a future contact is eligible
A missing permission or queue membership
A blocked action into an allowed one
The prior closure outcome
Mandatory tasks left unmet at closure

A snooze that quietly stopped a mandatory response clock, or an escalation that turned a blocked action into a permitted one, would make these controls a way around the rules rather than a way through them.

The six controls

Each control names its required inputs before it does anything.

Control	Required inputs	System effect
Wait/snooze	Reason, wake time or condition, expected version	Moves to waiting state and creates wake trigger.
Schedule contact	Purpose, channel, requested time, destination	Creates future task/interaction intent.
Reassign	Destination queue/worker and reason	Moves eligible task ownership.
Escalate	Reason, urgency, destination, response target	Raises case level and creates specialist work.
Reopen	New trigger and reason	Creates a new open interval on the same history.
Close	Structured outcome and exit evidence	Freezes completed interval.

Conflicting updates

curl -X POST "$BASE/v1/servicing/cases/1001/transitions" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: hbr-wait-for-documents-2027-05-01" \
  -d '{
    "targetStatus": "SNOOZED",
    "reason": "Waiting for the requested borrower documents.",
    "resumeDate": "2027-05-05"
  }'

The workflow validates the transition against the current stage and its exit or wake requirements. A concurrent update returns 409 and writes nothing. Two operators reading the same case a minute apart is ordinary, and the one who submits second would otherwise erase a decision they never saw.

Deadlines keep running

Waiting state distinguishes customer wait, external-party wait, scheduled follow-up, and operational hold. Each state declares which service-level clocks pause and which regulatory or contractual deadlines continue. A user cannot snooze away a mandatory response date, because a clock that stopped whenever somebody was waiting is one nobody ever misses on paper and everybody misses in fact.

The scheduled time is only a preference

At execution, the interaction re-resolves customer local time, consent, restrictions, contact frequency, case/loan state, and destination. If blocked, it records the blocked attempt or creates review; it does not keep retrying around the same control. A scheduler that retried until the gate happened to open would turn one refused contact into a run of attempts against a borrower who had asked to be left alone.

Escalation targets

Before escalating, GET /v1/servicing/cases/{caseId}/escalation-targets enumerates the valid destinations under the same escalate authority: eligible queues, under-capacity specialists, supervisors, and compliance reviewers. At-capacity workers disappear from the lists rather than being marked, and the escalating command revalidates whichever target is chosen. Showing somebody who cannot take the work is how an urgent case lands on a full desk and sits there until its response deadline passes.

{
  "caseId": 1001,
  "queues": [{ "queueCode": "ESCALATION", "displayName": "Escalation" }],
  "people": [{ "workerId": 4103, "displayName": "Evan Escalation", "activeTaskCount": 3, "capacity": 6 }],
  "supervisors": [{ "workerId": 4103, "displayName": "Evan Escalation", "activeTaskCount": 3, "capacity": 6 }],
  "complianceReviewers": [{ "workerId": 4104, "displayName": "Cora Compliance", "activeTaskCount": 1 }]
}

The escalation command names an explicit target — a person, a queue, a supervisor, or a compliance reviewer — with a required urgency and response deadline.

curl -X POST "$BASE/v1/servicing/cases/1001/escalate" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: escalate-hbr-vulnerability" \
  -d '{
    "targetType": "SUPERVISOR",
    "targetRef": "4102",
    "reason": "Customer requested specialist support.",
    "urgency": "URGENT",
    "responseDeadline": "2027-05-02T17:00:00-07:00"
  }'

Escalation preserves the existing case and links the new task, urgency, service-level effect, owner, decision, and return path.

Reopen never erases the prior closure

Closure requires structured outcome, reason, all mandatory stage criteria, and current authoritative facts. Reopen creates a new trigger event and current workflow state while retaining the previous closed interval and evidence — so a case worked three times reads as three intervals with three outcomes, rather than as one matter whose earlier answers have been written over.

A control prepared under one case version may be stale. Use optimistic concurrency and re-read current state after a conflict; never retry a different transition blindly.