Cases

Case Management is the investigation hub of the Didit Console. Every AML hit, flagged verification, or suspicious transaction can become a case your compliance team works from open to resolution, with a full audit trail.

---

​

Lifecycle

A case moves through exactly three statuses: Resolving a case requires a resolution: Every case also carries a priority (Low, Medium, High, default Medium) and an optional due date that drives SLA sorting and overdue flags.

​

One subject per case

Every case is anchored to exactly one user or one business. You cannot mix subjects on a single case, and you cannot attach a session, business session, or transaction that belongs to a different subject than the case, doing so returns a clear error. This keeps every case page focused: the subject card, risk overview, documents, and financial data all describe the same person or business the case investigates. To review a second entity, open (or create) a separate case.

​

Fraud Check source context

Creating a case from a Fraud Check session preserves its check ID, request ID, and the section the reviewer opened. The source card also records the session’s analyst status at case creation. The case decision and source decision remain separate. API clients can supply source_context with check_id, request_id, and source_section when creating a case. Include that request as a session entry in links. The check and linked session must belong to the selected application and to each other. The API reads the analyst status itself and rejects caller-supplied status, recommendation, or source-type fields in this context.

​

Lists

Case Management keeps Cases, Overview, and Assignment available in its top navigation. The Cases workspace provides Open, Awaiting user, Resolved, and All status views. Opening a case keeps the case queue beside its details on desktop. On mobile, use the breadcrumb to return to the queue. Search matches subject name or ID, tag, case number, case title, linked session ID, and linked transaction ID, so you can paste in a session or transaction UUID and land directly on its case. Filter chips: Blueprint, Created, Source, Assignee, Tag, plus Add filter for Priority and Due. Columns: Created (date and creator), Case details (title), Status, Blueprint, Subject (name and ID), Subject tags, Assignee, Priority, and Due date, with more available behind horizontal scroll and column configuration.

​

Sort and SLA

Sort by Created at (default) or Due date. Sorting by due date surfaces overdue cases first; a case is overdue once its due date has passed while it is still Open or Awaiting user, shown with a red due chip.

​

Saved views

Save the current combination of filters and columns as a named view with Save view, switch between views with Select a view, and reset with Clear filters. Views are personal and persist the same way other console table preferences do.

​

Bulk actions

Select multiple cases to:

• Assign to an officer. All selected cases must share the same blueprint, the console warns before submitting if they do not.
• Set status to Awaiting user, Reopen, or Resolve (with a resolution and optional note). Each case is evaluated independently, so a case blocked by an incomplete checklist or a missing required note is reported individually without failing the rest of the batch.

​

Exports

The list menu offers two CSV exports, delivered through the Reports page:

• All cases report, one row per case with status, resolution, priority, tags, linked transactions, and the last FIU report filed.
• SLA report, per-case timing metrics: hours to assignment, hours to resolution, overdue, and SLA-met flags.

​

Subject actions and retries

The subject card lets authorized reviewers change the subject status, add tags, add an internal note, or add the subject to the blocklist. These actions are separate from resolving the case. The Subject actions section records each requested action as Applied or Failed and identifies its reviewer and time. Use Retry action to retry a failed action after reviewing the current subject. An applied action is not executed again when its request is retried. API clients should send a unique client_reference with each request to the case’s entity-actions/ endpoint. Keep the same reference and input when retrying a request after a connection error. A changed input with the same reference returns 409. When a reference is supplied, inspect receipt.status: a 200 response can contain a failed receipt, meaning the action was not applied. Retrying a failed request requires retry: true, or a call to its action-receipts/{receipt_uuid}/retry/ endpoint. The history endpoint returns at most 20 receipts per page and supplies next_offset for additional results. Existing API clients that omit client_reference keep their previous response behavior.

​

Tags

Add tags to a case from its header (Add tag) to group related investigations, or filter and search by tag from the list. Tag changes are recorded on the case timeline.

​

Related pages

​

Customer messages

Use Message customer to preview a fixed request or review update for a verified contact. See Customer messages for delivery states, secure responses and the API workflow.

​

Discussion and pinned notes

Open the discussion button beside the case status to review notes while keeping the investigation in place. Use a note’s menu to reply or pin it. Pinned notes appear first, and replies show a short excerpt of their parent note. Pin changes are recorded in case activity and do not change source decisions. Confirming deletion permanently removes the note and its quoted excerpt from replies. Replies themselves remain available. Attachments are deleted unless another note still uses them. API clients can provide a client_reference UUID when adding a note. An unchanged retry returns the existing note without duplicating notifications. Reusing that reference for changed content or for a deleted note returns 409. Provide reply_to to reference a live note in the same case, and update is_pinned through the note’s PATCH endpoint.

​

Check for an existing investigation

The shared Create Case dialog checks for existing investigations for the selected user, business or linked source. Open an existing case to continue reviewing it. Closed cases remain visible so you can open them and decide whether to reopen them. To create a separate investigation, enter a reason for treating it as a different incident. The reason is saved with the new case and shown in its overview. The console rechecks for duplicates when you submit, including cases created by another reviewer while the dialog was open. API integrations can review POST .../cases/duplicates/ and set review_duplicates=true on case creation. When an existing investigation is found, creation returns 409 unless separate_incident_reason is provided. The duplicate review endpoint returns up to 20 cases per page, with next_offset for more results. Existing API integrations that omit the option retain their current creation behavior.