Ciclo de vida
Um caso passa por exatamente três estados:
Para resolver um caso é necessário indicar uma resolução:
Cada caso tem também uma prioridade (
Low, Medium, High, por omissão Medium) e uma data limite opcional, que determina a ordenação por SLA e os sinalizadores de atraso.
Não existem os estados
Under review, On hold ou Pending approval, nem gravidade Critical ou um eixo de tipo de caso. O ciclo de vida está deliberadamente fixo para que a análise, os SLA e as permissões sejam inequívocos em todos os casos, independentemente da forma como foram criados.Um sujeito por caso
Cada caso está associado a exatamente um utilizador ou a uma empresa. Não é possível misturar sujeitos num mesmo caso, nem associar a um caso uma sessão, uma sessão empresarial ou uma transação que pertença a um sujeito diferente do caso; nesse caso, é devolvido um erro claro. Isto mantém cada página de caso focada: o cartão do sujeito, a visão geral de risco, os documentos e os dados financeiros descrevem todos a mesma pessoa ou empresa que o caso investiga. Para analisar uma segunda entidade, abra (ou crie) um caso separado.Contexto de origem do Fraud Check
Ao criar um caso a partir de uma sessão do Fraud Check, são preservados o seu ID de verificação, o ID do pedido e a secção que o revisor abriu. O cartão de origem também regista o estado do analista da sessão no momento da criação do caso. A decisão do caso e a decisão da origem continuam separadas. Os clientes de API podem fornecersource_context com check_id, request_id e source_section ao criar um caso.
Inclua esse pedido como uma entrada session em links.
A verificação e a sessão associada devem pertencer à aplicação selecionada e uma à outra.
A API lê o estado do analista por si própria e rejeita os campos de estado, recomendação ou tipo de origem fornecidos pelo cliente neste contexto.
Listas
A Gestão de casos mantém Casos, Visão geral e Atribuição disponíveis na navegação superior. O espaço de trabalho de Casos disponibiliza as vistas por estado Abertos, A aguardar utilizador, Resolvidos e Todos. Ao abrir um caso, a fila de casos fica ao lado dos respetivos detalhes no computador. Em dispositivos móveis, use a navegação em migalhas para voltar à fila. A pesquisa corresponde ao nome ou ID do sujeito, à tag, ao número do caso, ao título do caso, ao ID da sessão associada e ao ID da transação associada. Assim, pode colar um UUID de sessão ou de transação e chegar diretamente ao respetivo caso. Chips de filtro: Modelo, Criada, Origem, Atribuído e Etiqueta, além de Adicionar filtro para Prioridade e Prazo. Colunas: Criada (data e criador), Detalhes do caso (título), Estado, Modelo, Sujeito (nome e ID), Tags do sujeito, Atribuído, Prioridade e Data limite. Há mais colunas disponíveis através de deslocamento horizontal e da configuração de colunas.Ordenação e SLA
Ordene por Criado em (predefinido) ou Data limite. Ordenar por data limite mostra primeiro os casos em atraso. Um caso está em atraso assim que a sua data limite tiver passado enquanto continuar Aberto ou a aguardar utilizador, e é assinalado com um chip vermelho de prazo.Vistas guardadas
Guarde a combinação atual de filtros e colunas como uma vista com nome através de Guardar vista, alterne entre vistas com Selecionar uma vista e reponha com Limpar filtros. As vistas são pessoais e são guardadas da mesma forma que as outras preferências de tabelas da consola.Ações em massa
Selecione vários casos para:- Atribuir a um responsável. Todos os casos selecionados têm de partilhar o mesmo modelo; a consola avisa antes de submeter se não partilharem.
- Definir estado para A aguardar utilizador, Reabrir ou Resolver (com uma resolução e uma nota opcional). Cada caso é avaliado de forma independente. Assim, um caso bloqueado por uma lista de verificação incompleta ou por uma nota obrigatória em falta é comunicado individualmente, sem fazer falhar o restante lote.
Exportações
O menu da lista oferece duas exportações em CSV, entregues através da página de Relatórios:- Relatório de todos os casos, com uma linha por caso, com estado, resolução, prioridade, tags, transações associadas e o último relatório FIU apresentado.
- Relatório de SLA, com métricas de tempo por caso: horas até à atribuição, horas até à resolução e indicadores de atraso e de SLA cumprido.
Ações sobre o sujeito e novas tentativas
O cartão do sujeito permite que os revisores autorizados alterem o estado do sujeito, adicionem tags, acrescentem uma nota interna ou adicionem o sujeito à lista de bloqueio. Estas ações são separadas da resolução do caso. A secção Ações sobre o sujeito regista cada ação pedida como Aplicada ou Falhada e identifica o seu revisor e a hora. Use Repetir ação para repetir uma ação falhada depois de rever o sujeito atual. Uma ação aplicada não é executada de novo quando o seu pedido é repetido. Os clientes de API devem enviar umclient_reference único com cada pedido ao endpoint entity-actions/ do caso.
Mantenha a mesma referência e os mesmos dados ao repetir um pedido após um erro de ligação.
Dados alterados com a mesma referência devolvem 409.
Quando for fornecida uma referência, verifique receipt.status: uma resposta 200 pode conter um recibo falhado, o que significa que a ação não foi aplicada.
Repetir um pedido falhado exige retry: true ou uma chamada ao endpoint action-receipts/{receipt_uuid}/retry/.
O endpoint de histórico devolve no máximo 20 recibos por página e fornece next_offset para obter resultados adicionais.
Os clientes de API existentes que omitem client_reference mantêm o comportamento de resposta anterior.
Tags
Adicione tags a um caso a partir do respetivo cabeçalho (Adicionar tag) para agrupar investigações relacionadas, ou filtre e pesquise por tag na lista. As alterações às tags ficam registadas na cronologia do caso.Páginas relacionadas
Criar casos
Todos os pontos de entrada: utilizadores, empresas, sessões, transações e conectores automáticos.
Blueprints
Configure a atribuição, a escalada, a transferência e o conteúdo da página do caso.
Lista de verificação
Condicione a resolução aos passos obrigatórios da investigação.
Revisão pelo princípio dos quatro olhos
Aprovação pelo criador e pelo revisor para resoluções sensíveis.
Mensagens ao cliente
Use Enviar mensagem para pré-visualizar um pedido predefinido ou uma atualização de revisão para um contacto verificado. Veja Mensagens ao cliente para os estados de entrega, as respostas seguras e o fluxo da API.Discussão e notas fixadas
Abra o botão de discussão junto ao estado do caso para rever as notas sem interromper a investigação. Use o menu de uma nota para responder ou fixá-la. As notas fixadas aparecem primeiro, e as respostas mostram um excerto curto da nota original. As alterações de fixação são registadas na atividade do caso e não alteram as decisões de origem. Ao confirmar a eliminação, a nota e o respetivo excerto citado nas respostas são removidos permanentemente. As próprias respostas continuam disponíveis. Os anexos são eliminados, a menos que outra nota ainda os utilize. Os clientes da API podem indicar um UUID emclient_reference ao adicionar uma nota.
Uma nova tentativa sem alterações devolve a nota existente, sem duplicar notificações.
Reutilizar essa referência para conteúdo alterado ou para uma nota eliminada devolve 409.
Indique reply_to para referenciar uma nota ativa do mesmo caso, e atualize is_pinned através do endpoint PATCH da nota.
Verificar se já existe uma investigação
O diálogo partilhado Criar caso verifica se existem investigações para o utilizador, a empresa ou a origem associada selecionados. Abra um caso existente para continuar a sua análise. Os casos fechados continuam visíveis, para que possa abri-los e decidir se os reabre. Para criar uma investigação separada, indique o motivo para tratar o caso como um incidente diferente. O motivo fica guardado com o novo caso e é apresentado na respetiva visão geral. A consola volta a verificar duplicados ao submeter, incluindo casos criados por outro revisor enquanto o diálogo estava aberto. As integrações de API podem consultarPOST .../cases/duplicates/ e definir review_duplicates=true na criação do caso.
Quando é encontrada uma investigação existente, a criação devolve 409, a menos que seja indicado separate_incident_reason.
O endpoint de revisão de duplicados devolve até 20 casos por página, com next_offset para mais resultados.
As integrações de API existentes que omitem a opção mantêm o comportamento atual de criação.