Deleting a case with justification

A case loaded by mistake, duplicated or with inconsistent data no longer needs technical intervention to go away — and it should never go away without a trace. Straight from the case dashboard, anyone with the right permission removes the case with a mandatory justification, and the platform handles the rest: it deletes everything that belongs only to that case, preserves what is shared, takes its passages out of search and chat, and records who deleted it, when and why in the audit trail.

Destructive, audited operation. Deletion removes the case with its documents, indexed passages and audits, and cannot be undone through the interface.

Before this, removing a case required manual intervention directly in the graph database — with no auditable trace and a real risk of deleting shared entities by mistake. And even then, the case's passages stayed in the search base, reappearing in queries and in chat.

What is removed — and what is preserved

Deletion is surgical: it removes only what belongs exclusively to the case —

• the documents linked to it and each document's indexed passages;
• the audits (triage reports) and each audit's passages.

Shared entities — people, companies, adjudicating bodies, judges, themes — that may belong to other cases are preserved intact.

The removal is end to end: the case disappears from the dashboard immediately and its passages stop appearing in search and chat.

Step by step

1. Open the case dashboard (Workspace›Painel de Processos).
2. Find the case row. If you have the permission, you will see the trash icon in the action column (next to the reprocess button).
3. Click the trash icon. The Excluir processo window opens.
4. Read the warning — the action removes the case, its documents and audits, and cannot be undone — and fill in the justification (mandatory for the audit trail). Without it, the confirm button stays disabled.
5. Click Excluir processo.
6. On success, the row disappears from the dashboard and a green notice confirms it ("Processo excluído."). If something goes wrong, the message is clear and in Portuguese — for example, permission denied or case not found.
7. The totals at the top and the pagination total are recounted right away, already without the deleted case. If it was the last row on a page, the dashboard steps back one page instead of leaving you on an empty one.

The operation counts how many documents, how many audits and how many passages were removed — the same numbers that are recorded in the audit trail.

Practical example

1. While reviewing the collection, you notice that case 0001234-56.2024… was loaded twice.
2. On the case dashboard, click the trash icon on the duplicated row.
3. Justification: "Processo duplicado, carregado por engano na ingestão de 15/07."
4. Confirm with Excluir processo. The duplicate disappears from the dashboard, from search and from chat — and the original stays intact, with all parties and shared entities preserved.

Who can delete

• Deletion requires the PROCESSOS_DELETE permission (category PROCESSOS, flagged as sensitive: "Excluir processos do painel (operação destrutiva, exige justificativa em auditoria)"). By default it is granted to the ADMIN and ADVANCED_USER roles. As with every sensitive permission, prefer restricting it to profiles with curation responsibility — adjust it in Sistema›Segurança›Roles e Permissões.
• The trash icon only appears for those who have the permission, but that is just a visual hint. The real barrier is on the platform side: without the permission, the deletion is denied regardless of what the interface shows. Being authenticated is not enough.

Audit trail

Every deletion records the PROCESSOS.PROCESSO_DELETED event with who deleted it (the authenticated user; with no identity, system), which case, in which context, how many documents, audits and passages were removed, and the justification provided. The justification is sanitized (quotes and line breaks are stripped) so it does not break the record format.

The events go to the platform's log index (otel-logs-*), correlated by trace_id / span_id — the deletion leaves a complete trace, from the click through to the graph and search-base operations.

What happens behind the scenes

• Dashboard cache invalidated immediately. Right after the removal in the graph, the case dashboard cache is cleared (local memory plus shared keys under datta:processos:dashboard:*), along with the schema cache. That way the deleted case does not reappear within the dashboard's 60s cache window.
• Search cleanup in the background. Taking the passages out of the search base is best-effort: it neither blocks the response nor undoes the deletion in the graph. The sweep matches three record families in the context index — the full-text records, the legacy passages and the passages with no case number filled in. Filtering by the number alone left orphaned records: in the full cleanup of 2026-07-17, 483 records matched and 733 did not. On that same occasion, 575 passages were left orphaned in the graph — which is why document passages now enter the deletion cascade.
• Tolerant to a hot index. Version conflicts during the cleanup do not abort the operation; the sweep runs to the end.
• Document codes collected first. The document codes are read before the removal in the graph, precisely so they can feed the search-base cleanup.
• The case number travels as a parameter, not inside the address. Superior court numbering carries a slash — AREsp 1.627.029/RS is the real case. A slash inside the address is refused by the platform before authentication even happens, and the refusal came back with no message: the screen showed the generic warning "Não foi possível excluir o processo. Tente novamente." for a request that had never reached the server — and which, for that reason, left no log entry to look for either. Passing the number as a parameter lets the slash through. The same applies to assigning the owner and to downloading the case PDFs.

How to operate it (administrator)

• Investigating deletions: query the platform records filtering by event=PROCESSOS.PROCESSO_DELETED to see the author, the case number, the context, the counts and the justification.
• Orphaned passages: if the search-base cleanup fails, a warning is recorded in the platform logs. The cleanup can be re-run through the equivalent internal operation, which requires the SEARCH_EXECUTE permission, is idempotent and accepts the list of document codes — provide that list to also cover the full-text records and the legacy passages; without it, only the case number is matched.

Known limitations

• No undo through the interface: the deletion is final. If data still exists but is disconnected, the operations team has a recovery procedure.
• Document shared between cases: if a document was linked to more than one case, it (and its passages) is removed together with the deleted case.
• Search cleanup is asynchronous: the confirmation guarantees the removal in the graph; taking the passages out of search happens next and, if it fails, is recorded in a log without reverting the deletion.
• The right context: the deletion acts on the context provided or, in its absence, on the active context. In the wrong context the case is simply not found — nothing is deleted by mistake. If no active context is configured, the platform tells you to register one in Sistema.

Deletion is also available to integrations, with the same justification requirement, the same permission check and the same audit trail — the routes are in the API reference.