Case model & lifecycle
Model a borrower or merchant matter as a durable workflow with explicit states, tasks, interactions, decisions, evidence, service levels, and closure criteria.
A case is the durable record of one servicing matter. It holds the reason work exists, the facts and policy used, what happened, and what remains—not merely the current assignee’s task.
Case, task, interaction, action
| Record | Answers | Example |
|---|---|---|
| Case | Why does this matter exist, and when is it resolved? | Harbor is 22 days past due. |
| Task | Who should do the next unit of work? | Review contact eligibility and call. |
| Interaction | What communication occurred? | Outbound call reached Maya. |
| Decision | What did policy allow or require? | Voice allowed; three counted calls remain. |
| Action request | What state change was proposed and applied? | Create a $517.14 promise for August 2. |
| Evidence | Which facts, versions, and approvals support it? | Delinquency snapshot, rule trace, call recording. |
Closing a task never silently closes its case. Each record has its own lifecycle and links through stable IDs.
Case lifecycle
SNOOZED, ESCALATED, and FAILED_ACTION_REVIEW are also available where a workflow needs them. Transition eligibility comes from the case’s pinned workflow version; arbitrary status updates are rejected.
Required fields
POST /v1/servicing/cases
Idempotency-Key: harbor-delinquency-2027-05-01
{
"caseType": "collections",
"customerId": "412",
"loanIds": ["7204"],
"source": "delinquency_monitor",
"reasonCode": "installment_past_due",
"priority": "high",
"sourceReference": "signal_2027-05-01_HBR",
"initialFacts": {
"daysPastDue": 22,
"amountPastDue": "517.14",
"asOf": "2027-05-01T08:00:00-07:00"
}
}The response includes the workflow version, assigned queue, current stage, next action, service-level deadlines, and deduplication result. The initial facts help explain intake; they are not trusted forever. Execution-sensitive actions re-read authoritative facts.
Case catalog
LendEasy exposes a broad catalog while letting each tenant enable, rename, route, and configure its workflows.
| Domain | Case types |
|---|---|
| Account service | General support, account correction, statement inquiry, payoff inquiry, document request |
| Payments | Payment issue, returned payment, card dispute, external payment review, credit balance, refund |
| Autopay | Enrollment support, authorization dispute, repeated failure, instrument replacement |
| Collections | Early delinquency, late-stage collections, promise follow-up, hardship, disaster assistance |
| Legal and compliance | Bankruptcy, cease communications, debt dispute, debt validation, servicemember protection, deceased customer |
| Identity and authority | Identity theft, suspected fraud, authorized-party review, verification failure |
| Complaints and privacy | Complaint, privacy request, data correction, communication preference dispute |
| Merchant servicing | Sales-report exception, remittance recovery, near-breach review, contract breach, merchant support |
| Operations | Reconciliation drift, failed action, duplicate record, document classification review |
Case types do more than label work. Each pins its stages, fact requirements, restriction rules, tasks, allowed actions, approvals, outcome codes, and closure criteria. A bankruptcy case therefore cannot accidentally use a collections workflow just because both concern a past-due loan.
Workflow stages and exit criteria
A case’s status is cross-platform; its stage is case-type-specific. A bankruptcy workflow might use notice_received → evidence_review → restrictions_applied → ongoing_monitoring → release_review. Exiting evidence_review could require either verified filing data or a documented reason that the notice could not be substantiated.
Every stage declares:
- required and optional facts;
- tasks created on entry;
- permitted interaction reasons and actions;
- compliance evaluations and approvals;
- timers, escalation paths, and wake events;
- exit criteria; and
- acceptable outcomes.
Workflow edits create a new version. Active cases remain on their pinned version unless a governed migration records the before/after stage map.
Live context versus action snapshot
The case header shows current borrower, loan, delinquency, contact, promise, restriction, document, and interaction facts. Material decisions also store a point-in-time snapshot.
For a collection call, the action snapshot includes:
- amount and days past due;
- last posted payment and covering in-flight amount;
- active promise and contact-suppression facts;
- verified contact point, consent, timezone, and convenient-time facts;
- remaining contact budget by debt and channel;
- bankruptcy, cease, dispute, fraud, and other restrictions; and
- source,
asOf, freshness status, and policy versions.
That snapshot answers “why was this allowed then?” without implying it remains allowed now.
Notes and sensitive material
Notes are typed: normal, pinned, sensitive, legal, and internal review. Access policy follows note type, and exports redact fields the caller cannot view. A note cannot serve as the only record of a consent revocation, bankruptcy filing, promise, approval, or loan action; structured records own those facts.
Resolution and closure
Resolving requires an outcome plus satisfied closure criteria. Closing finalizes reporting fields and cancels or completes remaining work under policy. Examples:
- A collections case resolves
promise_keptonly after authoritative payment facts satisfy the commitment. - A payment-return case resolves
recoveredonly after the replacement payment posts. - A bankruptcy case does not close merely because a task was completed; the workflow requires the appropriate stay/discharge outcome.
- A duplicate case closes
duplicatewith a surviving case link and preserves its source event.
Reopening creates a new lifecycle segment with trigger, actor, and reason. It never deletes the prior resolution.