Ciclo de vida
Um caso passa por exatamente três status:
Para resolver um caso, é obrigatório informar uma resolução:
Todo caso também tem uma prioridade (
Low, Medium, High, padrão Medium) e uma data de vencimento opcional, que define a ordenação por SLA e as sinalizações de atraso.
Não existe status
Under review, On hold ou Pending approval, nem severidade Critical ou classificação por tipo de caso. O ciclo de vida é fixo de propósito, para que análises, SLAs e permissões sejam inequívocos em todos os casos, independentemente de como cada um foi criado.Uma entidade por caso
Todo caso está vinculado a exatamente um usuário ou uma empresa. Não é possível misturar entidades em um mesmo caso, nem anexar uma sessão, sessão de empresa ou transação que pertença a um entidade diferente da do caso: isso retorna um erro claro. Assim, cada página de caso permanece focada: o card da entidade, a visão geral de risco, os documentos e os dados financeiros descrevem a mesma pessoa ou empresa investigada no caso. Para analisar uma segunda entidade, abra (ou crie) um caso separado.Contexto de origem do Fraud Check
Criar um caso a partir de uma sessão do Fraud Check preserva o ID da verificação, o ID da requisição e a seção que o revisor abriu. O cartão de origem também registra o status do analista na sessão no momento da criação do caso. A decisão do caso e a decisão da origem permanecem separadas. Clientes da API podem enviarsource_context com check_id, request_id e source_section ao criar um caso.
Inclua essa requisição como uma entrada session em links.
A verificação e a sessão vinculada devem pertencer à aplicação selecionada e uma à outra.
A própria API lê o status do analista e rejeita campos de status, recomendação ou tipo de origem enviados pelo chamador nesse 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 Casos oferece as visualizações de status Aberto, Aguardando usuário, Resolvidos e Todos. No desktop, ao abrir um caso, a fila de casos continua visível ao lado dos detalhes. No celular, use a trilha de navegação para voltar à fila. A busca encontra correspondências por nome ou ID do sujeito, tag, número do caso, título do caso, ID da sessão vinculada e ID da transação vinculada, então você pode colar o UUID de uma sessão ou transação e ir direto para o caso correspondente. Filtros rápidos: Modelo, Criada, Origem, Responsável, Tag, além de Adicionar filtro para Prioridade e Vencimento. Colunas: Criada (data e criador), Detalhes do caso (título), Status, Modelo, Sujeito (nome e ID), Tags do sujeito, Atribuído, Prioridade e Data de vencimento, com mais colunas disponíveis pela rolagem horizontal e pela configuração de colunas.Ordenação e SLA
Ordene por Criado em (padrão) ou Data de vencimento. A ordenação por data de vencimento mostra primeiro os casos atrasados. Um caso fica atrasado quando a data de vencimento já passou enquanto ele ainda está Aberto ou Aguardando usuário, e isso aparece com um indicador de vencimento vermelho.Visualizações salvas
Salve a combinação atual de filtros e colunas como uma visualização nomeada com Salvar visualização, alterne entre visualizações com Selecionar uma visualização e redefina com Limpar filtros. As visualizações são pessoais e persistem da mesma forma que as outras preferências de tabela do console.Ações em massa
Selecione vários casos para:- Atribuir a um responsável. Todos os casos selecionados devem compartilhar o mesmo modelo. Se não compartilharem, o console avisa antes do envio.
- Definir status como Aguardando usuário, Reabrir ou Resolver (com uma resolução e uma nota opcional). Cada caso é avaliado de forma independente, então um caso bloqueado por uma checklist incompleta ou pela falta de uma nota obrigatória é informado individualmente, sem fazer o restante do lote falhar.
Exportações
O menu da lista oferece duas exportações em CSV, disponibilizadas na página de Relatórios:- Relatório de todos os casos, com uma linha por caso contendo status, resolução, prioridade, tags, transações vinculadas e o último relatório enviado à FIU.
- Relatório de SLA, com métricas de tempo por caso: horas até a atribuição, horas até a resolução, indicadores de atraso e de cumprimento do SLA.
Ações sobre o sujeito e novas tentativas
O cartão do sujeito permite que revisores autorizados alterem o status do sujeito, adicionem tags, adicionem uma nota interna ou incluam o sujeito na lista de bloqueio. Essas ações são separadas da resolução do caso. A seção Subject actions registra cada ação solicitada como Applied ou Failed e identifica o revisor e o horário. Use Retry action para tentar novamente uma ação que falhou, depois de revisar o sujeito atual. Uma ação aplicada não é executada de novo quando a requisição dela é repetida. Clientes da API devem enviar umclient_reference único em cada requisição ao endpoint entity-actions/ do caso.
Mantenha a mesma referência e os mesmos dados de entrada ao repetir uma requisição após um erro de conexão.
Dados de entrada alterados com a mesma referência retorna 409.
Quando uma referência for enviada, verifique receipt.status: uma resposta 200 pode conter um recibo com falha, o que significa que a ação não foi aplicada.
Para tentar novamente uma requisição que falhou, é necessário retry: true ou uma chamada ao endpoint action-receipts/{receipt_uuid}/retry/ correspondente.
O endpoint de histórico retorna no máximo 20 recibos por página e fornece next_offset para resultados adicionais.
Clientes da API existentes que omitem client_reference mantêm o comportamento de resposta anterior.
Tags
Adicione tags a um caso pelo cabeçalho (Adicionar tag) para agrupar investigações relacionadas, ou filtre e pesquise por tag na lista. As alterações de tags ficam registradas na linha do tempo do caso.Páginas relacionadas
Criação de casos
Todos os pontos de entrada: usuários, empresas, sessões, transações e conectores automáticos.
Blueprints
Configure a atribuição, o escalonamento, a transferência e o conteúdo da página do caso.
Checklist
Condicione a resolução às etapas de investigação obrigatórias.
Revisão a quatro olhos
Aprovação maker/checker para resoluções sensíveis.
Mensagens ao cliente
Use Enviar mensagem para pré-visualizar uma solicitação predefinida ou uma atualização sobre a revisão para um contato verificado. Consulte Mensagens ao cliente para ver os status de entrega, as respostas seguras e o fluxo pela API.Discussão e notas fixadas
Abra o botão de discussão ao lado do status do caso para revisar as notas sem sair da investigação. Use o menu de uma nota para respondê-la ou fixá-la. As notas fixadas aparecem primeiro, e as respostas mostram um pequeno trecho da nota principal. As alterações de fixação ficam registradas na atividade do caso e não alteram as decisões de origem. Ao confirmar a exclusão, você remove permanentemente a nota e o trecho dela citado nas respostas. As respostas em si continuam disponíveis. Os anexos são excluídos, a menos que outra nota ainda os utilize. Os clientes de API podem informar um UUIDclient_reference ao adicionar uma nota.
Uma nova tentativa sem alterações retorna a nota existente, sem duplicar notificações.
Reutilizar essa referência com conteúdo alterado ou para uma nota excluída retorna 409.
Informe reply_to para referenciar uma nota ativa do mesmo caso e atualize is_pinned pelo endpoint PATCH da nota.
Verificar se já existe uma investigação
A caixa de diálogo compartilhada do Create Case verifica se já existem investigações para o usuário, a empresa ou a origem vinculada selecionada. Abra um caso existente para continuar a revisá-lo. Os casos encerrados continuam visíveis para que você possa abri-los e decidir se deve reabri-los. Para criar uma investigação separada, informe um motivo para tratá-la como um incidente diferente. O motivo é salvo com o novo caso e exibido na visão geral dele. O console verifica novamente se há duplicatas ao enviar, incluindo casos criados por outro revisor enquanto a caixa de diálogo estava aberta. As integrações via API podem consultarPOST .../cases/duplicates/ e definir review_duplicates=true na criação do caso.
Quando uma investigação existente é encontrada, a criação retorna 409, a menos que separate_incident_reason seja informado.
O endpoint de revisão de duplicatas retorna até 20 casos por página, com next_offset para mais resultados.
As integrações via API existentes que omitem essa opção mantêm o comportamento atual de criação.