DATTA BPM — Workflows with Built-in Screening

Coordinating the path of hundreds of cases — who does what, in what order, by when — in spreadsheets and message threads is a recipe for missed deadlines and forgotten steps. With DATTA BPM you draw the workflow visually in BPMN 2.0 notation (judicial case, loan application, social benefit application…), choose which screening rules run at each phase and follow every case in real time — with deadlines the platform enforces on its own, automatic decisions driven by the screening results and consolidated reports in DATTABI.

Menu: DATTA BPM›Process Modeler and DATTA BPM›Process Monitor.

Concepts

How to draw a flow in the Modeler

1. New model: enter a name, a description and the case context — the database the flow orchestrates (drives auto-start and the registration of existing cases). Without a context, the platform's active context applies. The context is set at creation and appears as a badge in the editor bar (there is no selector there): the screening rules do not depend on this field — they are chosen inside each task or decision (item 4).
   • The context must exist in the platform registry. A filled-in context that is not registered is refused right away, with the list of accepted contexts (the same keys the platform uses — Processos, CPC, …). Leaving the field blank is still valid and is the way to build a flow that is not tied to a context. The check applies to all three write paths: create, edit and publish — including when the context comes declared in the XML (datta:contexto), the case of an imported .bpmn file. Why it matters: the instance inherits the context from the model, so a non-existent context here produces instances that can never read the database — they end up with no owner and no descriptive title, and the symptom only showed up much later, in another service's log.
   • An old model with an invalid context stays editable: the check only refuses a value that changes. Renaming, editing the diagram or publishing a model that was already stored with a non-existent context is not blocked — otherwise it would be impossible to fix the model from the screen itself.
   • A context registry that is down does not block you: if the platform cannot read the list, the context you entered is accepted and the event is recorded in the service log. This is a format check, not a permission check: one service being unavailable must not stop you from working.
2. Draw the flow by dragging elements from the palette (standard BPMN 2.0 — the same notation as Bizagi/Camunda Modeler). Supported elements: start event, end event (including terminate), user task, service task (screening), embedded subprocess, call activity, exclusive, parallel and inclusive gateways, timer and message events (start, intermediate and attached to a task) and the event-based gateway.
3. Form fields of a phase: select a user task and, in the properties panel, define the fields the assignee fills in when completing the phase — each field has a name (variable), a label, a type (text, number, yes/no, date, list), whether it is required, options (for list) and a default value. In the monitor, Concluir fase opens this typed form; required fields block completion until they are filled in, and the values become variables used in the gateway conditions. Compatible with standard BPMN 2.0: ioSpecification (dataInput/dataOutput = required) and property from imported models (Bizagi/Camunda) also become fields.
4. Rules on any task or decision: select a task (user or screening) or a gateway and click Selecionar regras — a window opens with a context filter, semantic search by rule name or text and selection of one or more rules. Each item shows the rule's legal context (CPC/CDC/CPP…).
   • Context filter: the list carries every context that has active rules, with the count next to it (CPC (1.076)), plus the option "Todos os contextos que posso ver" (all contexts I can see). A context whose rules are all inactive stays out — the window only selects active rules, so the option would lead nowhere. Only the contexts your user reaches appear — the cut is made on the server, from the workspaces you belong to, and asking for a context outside your access answers "Você não tem acesso a esse contexto de regras" instead of returning an empty list with no explanation.
   • Pre-selection: since rules are cataloged by legal context (detected per case during screening) while the model points to a case context (e.g. "Processos"), the model's context comes already selected when it has rules of its own. When it does not, the window opens on "all contexts I can see" and says why — it used to show the entire catalog without warning, and those rules looked like the model context's own.
   • A context with no rules returns an empty list, with the explanation "Este contexto ainda não tem regras — escolha outro contexto no filtro".
   • Full rule text: the list shows the first 160 characters of the statement; click the text (or Ver texto completo) to open a scrollable panel with the whole rule. It closes with Esc, a click outside or Fechar, and focus returns to the item it came from.
   • Semantic search looks inside the context chosen in the filter.
   • Switching contexts does not undo the selection: rules already checked stay recorded in the model, including those from another context.
   • Check "Falhar a fase se alguma regra retornar anomalia/erro" so that, when the flow reaches that point, an anomaly or critical anomaly makes the phase fail (the instance goes to EM_ERRO, re-executable in the monitor). Without the checkbox, the rules only feed the variables used in the decisions and the flow continues.
   • Rules belong to the element, never to the whole model: each task and each decision has its own selection. A badge with the count appears at the corner of the box or diamond in the diagram, so you can see at a glance where screening is bound and where it was left empty.
   • With no selection, behavior differs by type: in a screening task ALL of the context's active rules run; in a user task or gateway no rule runs at all. The panel warns in each case.
   • Rules bound to a join of parallel paths (a parallel or inclusive gateway reached by more than one path) are not executed — there the process merely waits for the sibling branches. Validation rejects the model in that case, so the configuration does not sit dead in silence.
5. Decision conditions: select an arrow leaving an exclusive gateway. The condition can be built in two ways, toggled at the top of the panel:
   • Assistant (visual): condition rows in the format variable + operator + value — the variable comes from a list with the screening result and the form fields defined in the diagram's own phases; the value is suggested according to the type (screening status, yes/no, list options, number). With more than one row, choose whether the flow requires ALL (AND) or ANY (OR). The generated expression appears below and is what gets saved in the model.
   • Script: a free field for advanced expressions, e.g.:

     qtdAnomalias > 0 && (statusTriagem == 'ANOMALIA' || temAnomaliaCritica)

Parentheses and mixing AND/OR are only editable here — the assistant warns and keeps script mode.

Mark one of the outputs as the default flow. Variables filled in by the screening: statusTriagem (CONFORME | ANOMALIA | ANOMALIA_CRITICA | INCONCLUSIVO), qtdAnomalias, qtdConformes, qtdSemContexto, qtdNaoAvaliadas, temAnomalia, temAnomaliaCritica, scoreTriagem — in addition to the variables provided when completing user tasks.

qtdSemContexto and qtdNaoAvaliadas are deliberately separate, and the distinction drives routing: the first counts rules the screening evaluated without finding the data in the case; the second counts rules the AI never got to evaluate because the call to the model failed. Until 2026-08-22 the second situation did not exist as data — the rule simply vanished from the report — and a condition written as qtdSemContexto == 0 would start taking a different branch because of a provider outage. If your flow needs to react to that, write the condition over qtdNaoAvaliadas.

1. Deadlines the platform enforces on its own (timer event): drag a timer boundary event onto a task and enter the duration in ISO 8601 format — PT48H (48 hours), P15D (15 days), PT30M (30 minutes). The panel shows the reading in Portuguese ("dispara 48 horas depois de chegar aqui") and rejects an invalid format before publication. Two behaviors, chosen in the panel itself:
   • Interrupt the activity (solid border): the deadline expired → the task is canceled and the flow follows the boundary's path. Use for a missed deadline.
   • Do not interrupt (dashed border): the task continues and a parallel path opens. Use for escalation — "notify the supervisor, but the analyst keeps working". With a cycle (R/PT24H), it reminds every 24 hours.

You can also use a timer event in the middle of the flow (the process simply waits that period) and a timer start event, which creates instances on its own at a date (timeDate) or periodically (R/PT24H). The deadline keeps counting even across platform restarts — nothing is lost.

1. Waiting for something external (message event): a message event makes the process stop until an external system signals that something happened (a document filed in the case, the defendant's response, a callback from another system) — without anyone having to keep watching the panel. Give the message a name (e.g. documento-juntado); correlation uses the case number by default, and the integrator publishes the message through the DATTA API (see the API reference) with the name, the correlation key and the variables:

   {"nome": "documento-juntado", "correlacao": "0007580-15.2012.4.04.0000",
    "variaveis": {"tipoDocumento": "contestacao"}}

The submitted variables enter the process and can be used in the decisions. In the monitor, Enviar mensagem does the same through the interface. A message start event creates a new instance when the message arrives, and a send event notifies other DATTA processes waiting for it.

If no process was waiting, the message is discarded (standard BPMN behavior) and the response reports that no recipient was reached — publish again once the process reaches the wait.

1. "Whichever comes first" (event-based gateway): for the pattern I wait for the response for up to 15 days; if it does not arrive, I take another path, use the event-based gateway with two outputs — one to a message event, the other to a timer event. Whichever happens first decides the path and cancels the other.
2. SLA (hours): an informative deadline per phase, shown in the monitor and in the reports. For a deadline the platform actually enforces, use the timer boundary event (item 6).
3. Save: on a draft, "Salvar" stores the diagram without publishing it, and Ctrl+S (Cmd+S on a Mac) does the same from the keyboard. Save as often as you like before publishing.
4. Validate and publish: validation points out structural problems in Portuguese (e.g. a phase without an outgoing flow, a gateway without conditions). Publishing makes the model executable. There are then two ways to change it, described in item 12: save straight into the published version (preserving in-flight instances) or create a new version (leaving them on the current one).
5. Saving changes to an already published model: opening a PUBLICADO model shows the Somente leitura (read-only) chip and the diagram stays editable. When you save, you pick between two outcomes — what separates them is what happens to the instances already running:
   • Salvar (primary action) writes straight into the published version, without changing version. In-flight instances are preserved at the step they are on and follow the new flow from there. This is the path for fixing a flow in production without stopping what is already executing. A confirmation shows how many instances will be preserved before it writes.
   • Salvar como nova versão creates the draft of the next version carrying your edits and leaves you in it, with "Salvar" and "Publicar" back. In-flight instances stay on the current version, with today's diagram, and only new processes use the new version.

When the direct save is refused: if an in-flight instance sits on a step your diagram removes, it would have nowhere to go — the modeler names the affected steps and instances and offers the new version, which by definition does not touch what is running. Renaming, moving, reconnecting or adding a step does not trigger this; only removing the step where an instance is waiting.

Both require the BPMN_DEPLOY permission; without it, the chip explains that the version cannot be changed and neither button is shown. Ctrl+S (Cmd+S) triggers the primary action — and since it opens the confirmation, the shortcut never writes without you seeing the impact.

1. Export/Import exchanges the BPMN 2.0 XML with external tools (Bizagi, Camunda Modeler).
2. Auto-start (published model): check "Iniciar automaticamente a cada novo processo do contexto" on the model card so that every NEW case of the context enters the flow without a manual step (see the section below).
3. Delete model: every model card has "Excluir". Instances in progress or in error block the deletion (complete or cancel them first); models with finished instances ask for a second confirmation to also erase the history (events and results). The action is audited and irreversible.

How a record (case, application, benefit) enters the flow

Five ways to associate a real matter with a model:

1. Manually, through the monitor — Iniciar processo: choose the model, enter the business key and, optionally, initial variables (e.g. valor=50000, renda=8000) that feed the gateway conditions. Numbers and true/false are converted automatically. Useful for manual flows (a work queue without screening) — it works as a lightweight form for the matter.
2. Automatically post-ingestion — turn on auto-start on a published model. Every NEW case entering the context (Upload, DATTA Extract, pipeline or integration) starts an instance on its own. Cases that already existed when you turned the option on are NOT reprocessed (baseline); there is a per-cycle cap so as not to flood the screening and AI queue.
3. Register existing cases (backfill) — on a published model's card, Registrar existentes creates an instance for EACH case already existing in the context (e.g. registering every judicial case under the CPC procedure). The instances are born stopped at the first phase — no screening is triggered at registration; already-registered ones are skipped, so you can run it again without fear. It complements auto-start, which covers only new cases from now on.
4. From the Case Panel — on a case's detail screen, use Atribuir a modelo BPM... to register it in a published model; Acompanhar no monitor opens the created instance.
5. Through an integration — external systems and the ingestion pipeline itself can create instances by providing the model, the business key, the title and the initial variables; see the API reference.

The business key is the link with the data: in a screening task, the platform looks up the corresponding case in the context's database and runs the phase's rules against it. If the key does not yet exist in the database, the screening phase fails (re-executable after the ingestion). Flows with only manual phases accept any key.

What you see in the Process Monitor

• Start process: choose a published model, enter the business key (e.g. the case number) and optional initial variables. The platform walks the flow automatically up to the first manual phase.
• Instance list with filters by model and key, updated live — the "live" indicator lights up when there are events.
• The counters are the status filter: the Instâncias / Em andamento / Concluídas / Em erro / Canceladas cards are clickable — clicking applies the status, clicking the already-active card goes back to all. There is no separate row of status buttons: the number and the filter are the same control.
• The title says WHICH case it is: for a judicial case the title carries the procedural class and the main party (e.g. "Mandado de Segurança — FUSOPAR PARAFUSOS LTDA"), with the number in the Chave column. A title written by whoever started the process (e.g. "Pedido R$ 50k — Ana") is preserved. The title comes from the context's database at read time, without rewriting the instance: fix the data in the database and the monitor follows.
• It only lists cases that exist: an instance whose business key no longer exists in the context's database is left out of the list and of the total. If the context's database is unavailable, nothing is hidden — showing too much is preferred over hiding a valid case.
• "Contexto não cadastrado" badge: an instance whose context does not exist in the platform registry shows an amber badge next to the key (and in the Contexto field of the detail view). Hover for the explanation: the case keeps executing normally, but the enrichment that comes from the context's database — owner and descriptive title — does not apply, because there is no database to read. The instance is not hidden: hiding the problem would destroy the trail to it. New models no longer fall into this (the context is checked at creation); the badge serves the instances created before that check. If the platform cannot read the registry, nothing is flagged — flagging on unavailability would accuse a valid context of not existing. Anyone with BPMN_DEPLOY can click the badge and go straight to the fix: the Trocar o contexto do modelo dialog opens already pointing at the model behind that instance (see Repointing the context of a flow).
• "Segue o contexto ativo" / "não segue o modelo" badge: a purple badge, next to the key and in the Contexto field of the detail view, for an instance that does not follow the context its own model declares. This is a different question from the amber badge above and must not be confused with it: there the context does not exist in the platform; here it exists, but this instance does not follow it. Two causes:
  • "segue o contexto ativo" — the instance has no pinned context, and a blank context means "resolve through the platform's active context on every read". Meanwhile the model declares another one. This is a legitimate state (which is why the badge only explains and offers no fix): repointing the model's context does not pin this instance. The detail view shows where it actually resolves — "ativo da plataforma (hoje Processos) — o modelo declara OnboardingPJ". The "hoje" ("today") is literal: the active context is global and may change after the screen loaded, so the sentence describes the moment rather than promising anything.
  • "não segue o modelo" — the instance has an explicit context different from the one the model declares (this happens when the model was repointed without migrating the instances). Here there is something to fix: anyone with BPMN_DEPLOY clicks the badge and lands on the Trocar o contexto do modelo dialog with migration ticked.
• Instance detail: diagram with the current phase highlighted (blue), completed phases (green) and errors (red); event timeline; rule results per phase (with the AI's explanation); current variables.
• Rules per step: since rules are bound to each task or decision point (not to the whole model), the Rule results panel shows a chip per step with the anomalias/total count — clicking narrows the list to that step. Steps with anomalies are highlighted in red. Clicking the box (or the diamond) in the diagram performs the same narrowing and outlines the selected step; clicking again goes back to All steps. Within each group the anomalies come first and the header summarizes "N anomaly(ies) in M rule(s)".
• Actions: Concluir fase on a manual phase (providing optional variables), Reexecutar regras on a failed phase, and canceling the instance (history preserved). Cancellation applies to instances in progress and in error — useful when the failed phase will not be re-executed (e.g. withdrawal); completed or already-canceled instances cannot be canceled. Screenings running at the moment of cancellation are interrupted and late results are discarded. Canceling a child instance (call activity) marks the parent's call phase as an error, re-executable. Canceling a parent with in-flight calls cascades: all still-active child (and grandchild) instances are canceled along with it, each with its own history preserved and the reason "O processo chamador foi cancelado".
• Case deletion on the platform: when you delete a case in the Processos panel, the BPM instances of that number (including call activities) are automatically removed from the monitor — with history — and the number becomes eligible for auto-start again if the case is reloaded. Unlike cancel (which preserves the history in the monitor), this removal follows the deletion of the case itself.
• Deadlines and waits: a phase stopped at a timer event shows the countdown ("dispara em 2h 14min"); a task with an attached deadline shows the deadline clock on its own card. Phases waiting for a message show the name of the expected message and the Enviar mensagem button, which publishes the message correlated with that case. When the event-based gateway is active, the monitor lists the candidates ("aguardando o que vier primeiro"). The timeline shows Aguardando evento, Prazo cumprido, Prazo expirado (amber), Mensagem recebida/enviada and Evento decidiu o caminho.
• Reports (tab): instances by status, completed phases × average time, bottlenecks (waiting now, with SLA), anomalies per rule and daily series. The Anomalias por regra de triagem panel has step chips: by default it sums the entire model, and choosing a task/decision shows only that step's anomalies — useful because each step has its own rule selection, and the model-wide sum mixes different selections.
• Gerar dashboard DATTABI: creates in DATTABI a consolidated dashboard of the model (KPIs, status, bottlenecks, anomalies per rule, time series) that can be published to any workspace.
• Open modeler: goes straight to the diagram of the open process — with an instance in the detail view, it opens that instance's model; on the list, it opens the filter's model. Without an instance or a filter (there is no single diagram to point at) it falls back to the model gallery.

Repointing the context of a flow

A wrong context on a model happens — the flow was created before the context was registered, or the name typed was not the registered one. Since the instance inherits the context from the model, fixing only the model would leave the instances pointing at the old place. The platform does both in a single operation, with a preview of the impact and an audit record.

Where it lives

• In the Modeler: the context in the editor bar is a button — click it (or Definir contexto when the model has none). It also works for a published model: the context is execution policy, not drawing.
• In the Monitor: click the contexto não cadastrado badge on the instance, either on the list or in the detail view. It leads to the model that produced the instance — that is where the context lives.

What the preview shows (before any write)

Once the destination is chosen, the dialog shows, side by side, from where and to where the enrichment will read: the context database, the entity (label) and the identification property on each side. Plus the counts: how many instances would be migrated, how many are already at the destination, how many follow the active context, and the total. The confirm button only enables after the preview appears and the reason is filled in — repointing changes which database the data comes from, and confirming that blind is the kind of decision you only find out was wrong later.

When there are instances with no pinned context, the preview does not merely state that they are left out: it states where they resolve to, using the active context at that moment — "2 instância(s) seguem o contexto ativo (hoje Processos) e continuarão seguindo; como o destino é OnboardingPJ, elas vão resolver para Processos, não para OnboardingPJ." If the platform cannot read which context is active right now, the sentence says so instead of promising a destination nobody verified.

What changes and what does not

• Changes: the model's context field and that of its instances that have an explicit context (when migration is ticked). The datta:contexto declared in the diagram is realigned as well, so the next published version does not undo the change.
• Does not change: status, current phase, tokens, variables, business key and the instances' history. A running instance stays exactly where it was — what changes is where the enrichment comes from, not the state of the flow.
• Nothing is copied between databases. The instance starts reading from another context; no data is moved from one database to another. And no instance is deleted.

The blank-context rule

An instance with no pinned context is never migrated — neither by this change nor by the cascade of renaming a context. A blank context does not mean "no context": it means "resolve through the platform's active context on every read". Writing a name there would turn a dynamic choice into a fixed one without anyone asking for it — and, the decisive point, with no way back: once the name is written, there is no longer any way to tell which instances were dynamic. Not touching is recoverable; touching is not. Between the reversible and the irreversible, the platform picks the reversible.

The price of this rule is a legitimate divergence — the model declares Y, the instance resolves through the active context — and it is announced, never silent: it shows up in the preview (above) and in the monitor, in the "segue o contexto ativo" badge on the list and in the Contexto field of the detail view. Anyone who wants to pin such an instance does it deliberately, not as a side effect of another operation.

Rules

• The destination must be registered: a non-existent context is refused with the same message used when creating the model, listing the accepted keys.
• The reason is mandatory and goes to the audit trail (BPMN.MODELO.CONTEXTO_ALTERADO, with who did it, origin, destination and count).
• Idempotent: an instance already at the destination is neither touched nor counted as migrated. Repeating the operation changes nothing.
• An instance with no pinned context stays out (see The blank-context rule): it counts neither as "to migrate" nor as "left in the previous context" — it is counted separately, because it would never be migrated anyway.
• It is per model, never "move everything that is KYB": the model carries the intent and the instance only inherits it — a per-context migration would cut across models with different owners, and a single reason would explain none of them. For a model with several versions, repeat the change on each version that has instances.
• Permission: BPMN_DEPLOY (the same one used to edit/publish a model). Without it, the badge still explains the problem but offers no action.

Instance owner

Every instance has one owner — the person answering for that case. It exists for follow-up and filtering; it is not a permission: anyone with BPMN_EXECUTE can still complete any phase, whether or not they own it.

Where it comes from

1. From the assignment made in the Process Panel. When you assign a case to a user, the platform records the owner on the case and propagates it to the BPM instances of that business key. An instance created afterwards is born with the current owner.
2. From this screen. In the list and in the detail, click the owner (or Sem responsável) to assign or reassign. Leaving the field blank releases the instance — going back to "no owner" is a legitimate state, not an error.

Every change is recorded in the audit trail as BPMN.INSTANCIA.RESPONSAVEL_ALTERADO, with who changed it, from whom to whom.

How to filter

On the Instâncias and Relatórios tabs the filter bar has a Responsável field, suggesting the registered users, plus two shortcuts:

The filter combines with model, status and business key. On the reports it applies to the four blocks at once (summary, phases, anomalies per rule and daily series) — report and list answer to the same filter, so the numbers match. Clicking the active shortcut again clears the filter.

History from before the feature

Instances created before this feature are born without an owner and show up under Sem responsável. An administrator can fill the history in one pass from the existing assignments; the operation is idempotent (re-running only reaches what is missing) and reports how many instances remain without an owner. The corresponding resource is described in the API reference.

Worked example — a screening queue with a deadline

1. In DATTA BPM›Process Modeler, create the model "Rito ordinário — triagem" in the "Processos" context: start → screening task → exclusive gateway → (compliant) end; (anomaly) user task "Revisão do analista" → end.
2. On the screening task, use Selecionar regras and pick the deadline and summons rules. On the gateway's anomaly arrow, use the assistant: temAnomalia + é verdadeiro; mark the other output as the default flow.
3. Drag a timer boundary event (interrupting, P5D) onto the "Revisão do analista" task, diverting to "Escalar ao supervisor".
4. Publish. On the model card, click Registrar existentes to put the current backlog into the flow and turn on auto-start for the new ones.
5. Follow along in DATTA BPM›Process Monitor: cases with anomalies stop at the review; if the analyst does not finish within 5 days, the platform diverts to the supervisor on its own. Close the loop with Gerar dashboard DATTABI for the executive view.

Permissions

Troubleshooting

• "Triagem falhou" / instance in error: check the AI's availability and use Reexecutar regras on the phase. The platform also recovers from restarts by marking interrupted executions for re-execution.
• "Nenhuma das regras selecionadas está ativa": the rule was deactivated/deleted in the rule registry after publication — publish a new version of the model with the updated selection.
• The case does not advance after the screening: check the gateway conditions — if no condition is satisfied and there is no default flow, the instance goes into error with a message pointing at the gateway.
• "O contexto '…' não está cadastrado na plataforma": the context entered in the model (or declared in the imported XML) does not exist in the registry. The message lists the accepted contexts — use one of them, leave the field blank, or register the context under Sistema›Contextos and try again (a newly registered context is recognised immediately, with no cache wait).
• An instance with the "contexto não cadastrado" badge: the context of the model behind that instance does not exist (or no longer exists) in the registry. Two ways out, neither requiring a command line: point the model at the right context — click the badge and use Trocar o contexto do modelo, which migrates the instances along (see Repointing the context of a flow) — or register the context with the same name under Sistema›Contextos, when the stored name is the correct one and only the registration was missing. No instance is deleted because of this: removing history is the operator's decision.
• The preview says "this context does not identify data by an entity": not an error. Not every context anchors its data on a root entity — a procedural-code corpus (CPC, CDC, CPP) holds articles, and a reference graph holds lookup data. For those there is no "case" to enrich: title and owner stay as recorded on the instance. Contexts that do anchor declare the entity and the identifying property in the registry (Sistema›Contextos) — for example Empresa/cnpj in a cadastral dossier. A model pointed at a context without an anchor also does not auto-start cases nor accept bulk registration: in both the trigger is the root entity, and the platform says so instead of silently returning zero.
• An instance disappeared from the context filter: the platform watches for this. Filters compare the context by exact equality (that is what keeps the lookup fast), and a stored value with surrounding whitespace — from an import or an older backup restore — would not match the clean name. The service checks this on every restart and publishes the bpmn_contexto_com_padding metric, which must be 0; above that, the log records a warning and the fix is to rename or repoint the context, which normalises the value.
• The monitor lists cases that no longer exist in the Processos panel: these are orphans from mass cleanups done outside the platform, prior to the deletion cascade. The operations team has a cleanup procedure.
• The deadline passed and the process did not divert: the deadline sweep runs every 15 seconds, so the trigger may be delayed by up to one cycle — normal. If it goes much beyond that, check the model: a deadline only applies while the case is on the watched task; if the phase was completed earlier, the deadline is disarmed on purpose (there is no posthumous trigger).
• "Nenhum processo estava aguardando esta mensagem": not an error. Either the process has not reached the wait yet, or the correlation key does not match — by default it is the case number (business key). Check the submitted key and publish again; messages are not stored waiting for a recipient.
• The owner filter comes back empty: check under Sem responsável. Instances created before this feature, or from cases that were never assigned, have no owner yet — assign them in the Process Panel or ask the administrator to fill in the history (see Instance owner).
• I assigned the case in the panel and the instance still has no owner: propagation is immediate, but it depends on the monitor being up at the moment of the assignment. Reassign from the monitor screen itself or repeat the assignment in the panel; the operation is idempotent.
• "Este modelo não tem diagrama": the model was published without the flow drawing, so there is nothing to show in the modeler or the monitor. The process still runs normally — instances advance and the phase panel shows progress; only the diagram is unavailable. To see it, publish a new version with the flow drawn. New models can no longer fall into this: publishing without a drawing is rejected at validation.
• "O XML pode estar corrompido": different from the case above — here the file itself is unreadable (a truncated or hand-edited .bpmn import). Re-import the original file or redraw the flow in the modeler.
• The model does not publish with a timer event: the expression must be ISO 8601 (PT48H, P15D, R/PT24H). The validation message points at the element and the expected format. Cycles below 60 seconds are rejected on purpose, so as not to create a storm of instances.