LendEasy/DocsLMS + Servicing·v1
Start integrating
Guides›Servicing Plane›Cases & queues

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 Which approval-required, deferred, manual, external, or unavailable change was materialized? Approve an out-of-guardrail promise.
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

Waiting and review states require a named dependency, owner, deadline, and wake condition. They are not parking lots.

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

The implemented create contract uses numeric servicing IDs, string references to authoritative customer/loan records, and exact source deduplication:

POST /v1/servicing/cases
Idempotency-Key: harbor-delinquency-2027-05-01

{
  "customerRef": "412",
  "caseTypeCode": "COLLECTIONS",
  "reasonCode": "DELINQUENCY_SIGNAL",
  "priority": "HIGH",
  "loanRefs": ["7204"],
  "sourceType": "LMS_EVENT",
  "sourceRef": "signal_2027-05-01_HBR"
}

The response separates caseId: 1001 from a durable external reference such as externalCaseRef: "LE-CASE-1001" and reports whether the exact source was deduplicated.

Enriched intake shape (roadmap)

The following intake shape is retained as product direction for callers that supply a richer initial fact snapshot:

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"
  }
}

In that enriched shape, 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.

The table above is the catalog LendEasy ships. What a given tenant has actually enabled is read from the API, not assumed: GET /v1/servicing/case-types returns the presentation-safe enabled types with their reasons, routing defaults, and current field definitions — everything an intake form needs to build itself:

{
  "items": [
    {
      "caseTypeCode": "COLLECTIONS",
      "displayName": "Collections",
      "defaultPriority": "NORMAL",
      "serviceLevelMinutes": 1440,
      "defaultQueueCode": "COLLECTIONS",
      "reasons": [
        { "reasonCode": "DELINQUENCY_SIGNAL", "displayName": "Delinquency signal", "handlingMode": "WORKFLOW" }
      ],
      "fieldDefinitions": { "sections": [] }
    }
  ]
}

Drive caseTypeCode, reasonCode, and the configured fields on create from this read. A hard-coded client list drifts the moment a tenant enables a type or retires a reason. The definitions themselves are administered separately — see Servicing configuration.

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.

The case workspace read narrates this journey directly. GET /v1/servicing/cases/{caseId} returns the pinned workflow with a stages array in definition order — each stage carries its state (COMPLETED, CURRENT, SKIPPED, or UPCOMING), ISO 8601 UTC entry and exit timestamps where history exists, prose descriptions where the definition provides them, and the workflow tasks bucketed under the stage that created them. The same read returns a workSummary with task counts and the next actionable task, the server-derived availableTransitions, owner and opener identity, and any openEscalation:

{
  "workflow": {
    "workflowKey": "COLLECTIONS_STANDARD",
    "version": 2,
    "status": "ACTIVE",
    "currentStageCode": "MONITOR_PROMISE",
    "stages": [
      {
        "stageKey": "INTAKE",
        "displayName": "Intake and route",
        "state": "COMPLETED",
        "enteredAt": "2027-05-04T16:11:02Z",
        "exitedAt": "2027-05-04T18:03:47Z",
        "tasks": [{ "taskId": 2001, "taskTypeCode": "COLLECTIONS_OUTREACH", "status": "COMPLETED", "outcomeCode": "CUSTOMER_REACHED" }]
      },
      { "stageKey": "MONITOR_PROMISE", "displayName": "Monitor the promise", "state": "CURRENT", "enteredAt": "2027-05-05T18:30:00Z", "tasks": [] }
    ]
  },
  "workSummary": {
    "taskCounts": { "COMPLETED": 1, "ACCEPTED": 1 },
    "openTaskCount": 1,
    "nextAction": { "taskId": 2002, "taskTypeCode": "COLLECTIONS_OUTREACH", "queueCode": "COLLECTIONS", "status": "ACCEPTED", "priority": "HIGH" }
  },
  "availableTransitions": ["SNOOZED", "WAITING_ON_BORROWER"]
}

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.

Updating a case

PUT /v1/servicing/cases/{caseId} updates routing-safe properties — priority, summary, and the configured fields — and always requires a reason:

{
  "priority": "HIGH",
  "summary": "Customer supplied the requested servicing details.",
  "fields": {
    "contact_outcome": "CUSTOMER_REACHED",
    "follow_up_date": "2027-05-07"
  },
  "reason": "Recorded the result of the customer call."
}

The command envelope reports exactly what moved, including the fieldKeys it accepted:

{
  "caseId": 1001,
  "resourceId": 1001,
  "changes": { "priority": "HIGH", "fieldKeys": ["contact_outcome", "follow_up_date"] }
}

Workflow state is not editable through this route. status changes go through the transition, close, and reopen commands below, so a client cannot reach a state the pinned workflow does not allow by writing a field.

Transition, close, reopen

Three separately authorized commands move a case through its lifecycle:

Command Requires Permission
POST /v1/servicing/cases/{caseId}/transitions targetStatus, reason (plus a resumeDate for waiting states) UPDATE_SERVICING_CASE
POST /v1/servicing/cases/{caseId}/close outcomeCode, closureReason CLOSE_SERVICING_CASE
POST /v1/servicing/cases/{caseId}/reopen reason (optionally priority, ownerQueueCode) REOPEN_SERVICING_CASE

The transition command applies one transition allowed by the case state machine and the pinned workflow — read availableTransitions from the workspace rather than guessing:

POST /v1/servicing/cases/1001/transitions

{
  "targetStatus": "SNOOZED",
  "reason": "Customer promised to pay on the agreed date.",
  "resumeDate": "2026-08-01"
}

Close and reopen are not transitions. Separating them keeps closure authority distinct from ordinary workflow movement, so a worker who can move a case to a waiting state cannot finalize it. See Case controls & escalation for what each control may and may not do.

Relationships between cases

Cases link rather than merge. POST /v1/servicing/cases/{caseId}/relationships creates a reversible RELATED or POSSIBLE_DUPLICATE link, and the relationship’s own subresources confirm, dismiss, or replace it. Confirming a possible duplicate names the selected duplicateCaseId; the other case stays primary and both histories remain intact. Duplicate detection & linking covers the signals and review model.

For a portfolio-wide event, the structural container is a supercase with linked customer subcases — see Mass cases & subcases.

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.

Case notes are revisioned rather than edited, and they are discoverable by case, customer, or loan. Case notes documents the create, revise, link, archive, and redact contracts.

Resolution and closure

Resolving requires an outcome plus satisfied closure criteria. Closing finalizes reporting fields and cancels or completes remaining work under policy. The close command enforces this: it succeeds only after required fields, tasks, action requests, case effects, and the workflow’s own closure criteria are satisfied.

POST /v1/servicing/cases/1001/close

{
  "outcomeCode": "PROMISE_KEPT",
  "closureReason": "Customer cured delinquency and no follow-up remains."
}

Examples:

  • A collections case resolves promise_kept only after authoritative payment facts satisfy the commitment.
  • A payment-return case resolves recovered only 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 duplicate with 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. POST /v1/servicing/cases/{caseId}/reopen re-routes the case under its configured workflow rules — the caller supplies the reason and may suggest priority and ownerQueueCode, but cannot assign the reopened matter to a chosen worker.

Unified search across guides, recipes & the API referenceEsc