> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Blueprints de casos - Atribuição e conteúdo de casos

> Configure no Didit a atribuição, escalonamento, transferência e apresentação de uma categoria de casos e instale os quatro presets incluídos.

Uma política de revisão, representada como um blueprint na API, define os requisitos para uma categoria de casos.
Gere as políticas em **Gestão de casos > Atribuição > Políticas de revisão**.
Os casos guardam a versão da política em vigor quando são abertos, pelo que as edições posteriores não alteram silenciosamente uma revisão em curso.
O editor envia a versão que abriu ao guardar.
Se outro revisor tiver publicado uma versão mais recente, ao guardar é devolvido um conflito e o rascunho continua aberto.
Reveja a política mais recente antes de voltar a aplicar as suas alterações.
As integrações de API podem enviar `expected_version` com uma atualização da política para a mesma proteção; uma versão desatualizada devolve `409` sem alterar a política.

***

## Definições gerais

| Definição | Descrição |
| - | - |
| **Nome** | Até 24 caracteres |
| **Descrição** | Opcional, texto livre |
| **Quem trata os casos** | Conjunto de responsáveis, obrigatório, com pelo menos um membro ("Escolha pelo menos um responsável") |
| **Atribuição** | **Manualmente**, ou **Automaticamente** |
| **Transferência de casos** | Interruptor; quando ativado, os casos podem passar para outro blueprint ativo da mesma aplicação |
| **Escalamento** | Interruptor e uma lista de seleção do blueprint de destino |
| **Revisão a 4 olhos** | Associar a um blueprint verificador, ver [Revisão a 4 olhos](https://docs.didit.me/pt/console/case-management/four-eyes.md) |
| **Exigir nota de resolução** | Interruptor; quando ativado, a nota do diálogo Resolver passa a ser obrigatória |
| **Prazo predefinido** | Prazo opcional, em horas, para novos casos; um prazo explícito do caso tem prioridade |

### Atribuição automática

A atribuição automática seleciona um revisor autorizado com o menor número de casos ativos em toda a organização, até à capacidade configurada.
Os agentes em linha têm prioridade quando estão disponíveis; caso contrário, podem receber casos os agentes offline elegíveis.
Quando todos os revisores elegíveis atingiram a capacidade, o caso fica sem atribuição.
A resolução de um caso ou a entrada de um agente em linha pode retirar um caso da fila quando houver capacidade disponível.

### Escalamento e transferência

O escalamento move um caso para um blueprint de destino fixo (a sua fila e a sua configuração de conteúdo) numa única ação. A transferência de casos, por sua vez, permite a um agente escolher qualquer blueprint ativo da mesma aplicação para mover um caso. Ambas ficam ocultas na página do caso, a menos que o blueprint atual as ative, e ambas são bloqueadas no servidor (400) se forem tentadas quando estão desativadas.

Um blueprint não pode referenciar-se a si próprio como destino de escalamento nem como verificador da revisão a 4 olhos.

### Fontes associadas

A barra lateral direita de um blueprint lista:

* **Origens de criação de casos**: configurações AML, regras de transação e nós de fluxo que encaminham atualmente novos casos para ele, com atalhos para cada um.
* **Recebe escalamentos de**: outros blueprints cujo destino de escalamento aponta para aqui.

## Guardar e publicar alterações à política

**Guardar rascunho** guarda as suas alterações sem afetar casos novos ou existentes.
Uma nova política fica não publicada e não pode ser selecionada para um caso ou regra de encaminhamento até escolher **Publicar**.
Reabrir o editor restaura o rascunho guardado.
**Publicar** fica disponível depois de as alterações atuais terem sido guardadas.
Publicar aplica essa versão a casos novos; os casos existentes mantêm os requisitos de revisão aceites.
**Histórico de versões** regista cada configuração publicada, a hora de publicação e o publicador, quando conhecido.
As políticas criadas antes de o histórico de versões estar disponível têm a sua base atual registada na publicação seguinte.
**Descartar rascunho** requer confirmação e devolve o editor à configuração publicada.
Descartar um rascunho nunca publicado elimina-o.

Tanto a gravação de rascunhos como a publicação verificam a versão publicada e a revisão do rascunho.
Se outra pessoa alterar uma delas, o servidor devolve `409` e o seu editor aberto mantém as edições não guardadas.
Um rascunho baseado numa política publicada mais antiga tem de ser revisto em relação à política atual antes de ser publicado.
As atualizações `PATCH` diretas da API continuam a ser publicações imediatas e também ficam registadas no histórico de versões.

### Rascunhos de regras de encaminhamento

As regras de encaminhamento usam as mesmas ações **Guardar rascunho**, **Publicar**, **Descartar rascunho** e **Histórico de versões**.
Guardar um rascunho não altera a regra usada para a atribuição automática nem a pré-visualização da regra publicada.
As alterações não publicadas têm de ser guardadas antes de poderem ser publicadas.
A publicação verifica se a política de revisão e a equipa selecionadas continuam ativas e pertencem à mesma aplicação.
Se outro editor alterar a regra ou o respetivo rascunho, a operação devolve um conflito e preserva as alterações mais recentes.
As novas regras usam primeiro **Guardar rascunho** e permanecem inativas até **Publicar** criar a versão 1.
Nas integrações de API, defina `publish=false` ao criar uma política ou uma regra de encaminhamento para usar este ciclo de vida.
Omitir a opção mantém a criação imediata para as integrações existentes.

## Biblioteca de predefinições

Instale qualquer uma das quatro predefinições incorporadas a partir da galeria de predefinições de políticas de revisão. A instalação copia a predefinição para a sua aplicação como um blueprint totalmente editável; pode depois alterar livremente qualquer definição sem afetar o catálogo. A instalação é idempotente por predefinição, pelo que reinstalar uma predefinição já instalada não tem efeito.

| Predefinição | Conteúdo do caso |
| - | - |
| **Resultado positivo de triagem** | Controlo AML (financeiro + identidade), identidade (informações pessoais, visão geral de risco) |
| **Investigação AML** | Controlo AML (financeiro), identidade (informações pessoais, informações de contacto, visão geral de risco, documentos PoI) |
| **Atividade suspeita** | Identidade (informações pessoais, visão geral de risco, documentos PoI), financeiro (métodos de pagamento, transações) |
| **Revisão KYC** | Identidade (todos os campos), resumo da verificação |

Nenhuma das predefinições configura previamente a atribuição, o escalamento, a revisão a 4 olhos ou a transferência; cabe-lhe sempre tomar essas decisões de encaminhamento para cada blueprint.

## Conteúdo do caso

O separador **Conteúdo do caso** controla os separadores e os campos que aparecem na página do caso, em seis secções que podem ser ativadas ou desativadas:

| Secção | Campos |
| - | - |
| **Lista de verificação** | Ativar, tornar opcional para a resolução, e a lista de itens da lista de verificação, ver [Lista de verificação](https://docs.didit.me/pt/console/case-management/checklist.md) |
| **Controlo AML** | Informações financeiras de AML, informações de identidade de AML |
| **Identidade** | Informação pessoal, etiquetas do requerente, informação de contacto, visão geral de risco, documentos comprovativos de identidade, documentos comprovativos de morada |
| **Verificações** | Resumo das verificações |
| **Relatórios** | Relatórios da FIU |
| **Dados e fontes financeiras** | Métodos de pagamento, transações financeiras |

Um blueprint sem secções ativadas continua a mostrar o separador Visão geral do caso, apenas sem os blocos de conteúdo extra.

> [!TIP]
>
> Use um prazo predefinido da política para dar aos novos casos uma janela de revisão consistente.
> Os revisores podem continuar a atualizar a prioridade e a data limite de um caso individual.
> Editar a política não altera os prazos dos casos existentes.

## Eliminar um blueprint

Eliminar um blueprint tem sempre êxito e não altera os seus casos: os casos existentes mantêm a referência ao blueprint, e as respetivas definições (secções de conteúdo, escalonamento, transferência, emparelhamento de 4-eyes) continuam a aplicar-se a eles. Um blueprint eliminado deixa de aparecer nas listas de blueprints e já não pode ser escolhido como destino de transferência. Se um blueprint de maker for eliminado enquanto uma das suas resoluções aguarda aprovação de 4-eyes, uma resolução rejeitada deixa o caso no blueprint de checker em vez de o devolver.

Para encerrar um blueprint de forma limpa, transferir os seus casos ativos para outro blueprint antes de o eliminar.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.