Mass cases & subcases · LendEasy Docs

A portfolio event gets one container and one subcase per customer, so thousands of matters can share a cause without ever sharing a decision.

A portfolio event opens one container and one case per affected customer, so thousands of matters share a cause without sharing a decision. A disaster, provider incident, statement defect or policy remediation can affect thousands of borrowers at once, and the tempting answer is one bulk action. One bulk action is one compliance decision applied to thousands of people who are not in the same position: some have paid, some have filed for bankruptcy, some asked last week not to be contacted.

This structural boundary is a bounded supercase: create, read, and list a supercase, and add idempotent customer subcases. The versioned-population, preview, canary, and bulk-status model is described at the end of this page.

the common cause

The supercase holds

One portfolio event, and one shared subcase case type
Status counts, and a direct link to the cases behind them

one customer

Each subcase holds

Its own workflow, tasks, compliance decisions, evidence and closure criteria
That customer's facts, controls, actions and outcome

Nothing can be done to the container. There is no route that acts on every case inside, which is what keeps a wildfire container from becoming a way to change ten thousand loans in one call.

A container with no authority of its own

A supercase names the portfolio event and the one subcase type it may hold:

curl -X POST "$BASE/v1/servicing/supercases" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "Content-Type: application/json" \
  -d '{
    "supercaseType": "FEMA",
    "displayName": "July wildfire assistance",
    "subcaseCaseTypeCode": "HARDSHIP",
    "createdSignalRef": "fema-event-2027-05",
    "sensitive": false
  }'

{
  "supercaseId": 8001,
  "externalSupercaseRef": "LE-SUPERCASE-8001",
  "status": "ACTIVE",
  "resourceId": 8001
}

supercaseType is a fixed list — GENERIC, FEMA, or REMEDIATION — and subcaseCaseTypeCode must name an enabled case type. Fixing one subcase type per supercase is what stops a disaster container from quietly accumulating unrelated regulated matters.

Each affected customer is added as an ordinary case that is structurally linked to the container:

POST /v1/servicing/supercases/8001/subcases

{
  "customerRef": "412",
  "reasonCode": "DISASTER_ASSISTANCE",
  "priority": "HIGH",
  "loanRefs": ["7204"],
  "ownerQueueCode": "HARDSHIP"
}

The response is a normal case creation result — caseId, externalCaseRef, status, and deduplicated — because that is exactly what it is. A subcase follows the full case model.

Reading a supercase

GET /v1/servicing/supercases lists bounded structural summaries, filterable by supercaseType, status, caseTypeCode, sensitive, and creation window. The point read adds those counts and the link:

{
  "supercaseId": 8001,
  "supercaseType": "FEMA",
  "displayName": "July wildfire assistance",
  "status": "ACTIVE",
  "subcaseCaseTypeCode": "HARDSHIP",
  "subcaseCount": 12,
  "subcaseStatusCounts": { "OPEN": 10, "CLOSED": 2 },
  "subcasesHref": "/v1/servicing/cases?supercaseId=8001"
}

Detailed subcases are read through the case collection at subcasesHref rather than through the supercase, so a progress figure can always be opened as the actual cases behind it. All four routes take MANAGE_SERVICING_SUPERCASE — container management, never a bypass of the permissions each subcase’s own operations require.