# Target Biográfico Documentação relacionada ao Target Biográfico e seu comportamento.\ Essa funcionalidade está disponível apenas a partir da versão 5 do GBDS. ## Comportamento ### Em geração de exceção Toda vez que uma exceção é gerada, um grupo correspondente é criado/atualizado com: * status: ANALYSIS * target: de acordo com o tipo de exceção; se há mais de uma exceção para um dado TGUID, o tipo do grupo é BIOMETRIC se houver alguma exceção BIOMETRIC * Sem prioridade * Organizações: todas as organizações de exceção apontando para o grupo e exceção com indicação de origem ENTRANT ou REFERENCE ### Em cada tratamento de exceção biométrica Caso não haja um grupo de exceção, ele será criado a partir dos TGUIDs das exceções #### Definição de Target * Caso haja alguma exceção BIOMETRIC\_MISMATCH, o grupo será definido como BIOMETRIC\_MISMATCH * Caso todas as exceções do sejam BIOMETRIC\_INCONCLUSIVE, BIOMETRIC\_MISMATCH ou BIOGRAPHIC: * BIOMETRIC\_MISMATCH se houver alguma exceção BIOMETRIC\_MISMATCH * BIOMETRIC\_INCONCLUSIVE se houver alguma exceção BIOMETRIC\_INCONCLUSIVE * Caso contrário, o grupo será do tipo BIOGRAPHIC * Caso a exceção tenha um resultado final associado, no caso em que todas as exceções para TGUID forem tratadas sem CSI, a decisão do grupo mudará: * Resultado final APPROVED, decisão do grupo é alterada para APPROVED * Se o resultado final for REJECT, a decisão do grupo é alterada para REJECT ### Priorização de exceção biométrica Quando uma exceção é priorizada usando endpoint set priority, o grupo também será priorizado Caso todas as exceções sejam despriorizadas, o grupo será despriorizado também (usando o mesmo endpoint) ### Próximo grupo de exceção Quando o próximo grupo de exceção é requisitado, ele deve ter: * status ANALYSIS * target BIOGRAPHIC, BIOMETRIC\_MISMATCH ou BIOMETRIC\_INCONCLUSIVE * Não estar alocado para ninguém * O grupo deve possuir uma organização dentre as organizações do usuário * Caso não tenha sido requisitada uma origem da organização, será considerado o grupo com todas as organizações * Caso a origem requisitada seja ENTRANT ou BOTH, será considerado o grupo com a organização na origem pedida. * Os grupos são ordenados por prioridade, pendência e data de criação em ordem crescente, por padrão * O usuário deve possuir permissão biográfica Com um grupo selecionado, o usuário será alocado para esse grupo por um dado tempo, de acordo com a configuração. Se a configuração tiver valor -1 o grupo nunca será desalocado e precisará ser desalocado manualmente através do endpoint **Unlock Group.** ### Alocação e desalocação manual Pode ser feito a partir dos endpoints **Lock group** e **Unlock group** Um grupo não pode ser alocado se ele já estiver alocado para outro usuário e não pode ser desalocado se não estiver alocado para o usuário em fornecido ### Para cada tratamento de grupo As validações a serem feitas são: * Usuário e permissões devem ser fornecidos, a menos que a segurança esteja ativada, nesse caso, ambos são fornecidos pelo token * Timeout é zero por padrão, quando o tratamento é final e a exceção é tratada como APPROVE, esse valor é utilizado * GGUID do grupo e o status de decisão do grupo (KEEP or REJECT) são obrigatórios * Grupo deve existir e estar em status/target ANALYSIS/BIOGRAPHIC, BIOMETRIC\_MISMATCH ou BIOMETRIC\_INCONCLUSIVE * Grupo deve estar alocado ao usuário * O usuário deve ter alguma organização presente no grupo * O usuário não pode ter tomado uma decisão para esse candidato anteriormente * A biometria deve estar alocada ao usuário Caso a decisão de status seja **KEEP**:\ **Cadastro -** Parâmetros devem ser fornecidos com pelo menos uma chave, biográficos e labels são opcionais e todos os TGUIDs a serem armazenados devem ser de exceções do grupo, do entrante ou da referência **Atualização -** os TGUIDs a serem armazenados devem ser de exceções do grupo, podem ser mantidos entrante e/ou referência. Se todas as validações forem aprovadas, a decisão do usuário, o usuário, comentários e parâmetros serão salvos no grupo ### Remocão de transações do grupo em tratamento Para remover transações que pertencam a exceções de BIOMETRIC\_MISMATCH ou BIOMETRIC\_INCONCLUSIVE as transações devem ser fornecidas através de parâmetros que serão removidos usando `removeTransactions` nos parâmetros. Nesse caso: * O grupo deve ser um grupo de exceção de cadastro * Não é permitido remover a transação entrante * As transações removidas devem ser do grupo de transações de referência de qualquer grupo de exceção biométrica inconclusiva ou não correspondente (mismatch) * Transações de remoção não devem conflitar com transações de permanência ### Decisão pendente Caso o usuário requisite uma rejeição de alguma transação cujas organizações não se encontram em suas organizações, o grupo é marcado com status PENDING e o tratamento do grupo é feito pelo endpoint `treat pending group` ### Atualização de grupo de exceção * REJECT: rejeita entrante e referência e deleta as referências * KEEP: mantém apenas referência * Rejeita todas as exceções * KEEP: mantém o entrante * Rejeita todas as exceções * Deleta as referências * Reenvia a transação entrante como cadastro * KEEP: referência e entrante são mantidos * Todas as exceções são aprovadas {% hint style="info" %} Caso sejam fornecidas transações para serem removidas, elas não serão aplicadas ao perfil unificado e seus perfis não serão deletados {% endhint %} ### Grupo em tratamento pendente Para grupos em que a decisão de tratamento está pendente, o tratamento é feito com o endpoint de `treat pending group` A validações diferem do tratamento regular em: * O grupo deve estar pendente de decisão * o usuário deve ter uma organização presente em todas as transações do grupo. Caso a transação seja rejeitada, o grupo volta para o status de ANALYSIS Se for aceita, o tratamento será feito como descrito acima. ### Prioridade Quando um grupo é priorizado ou despriorizado, todas as exceções para o mesmo grupo são afetadas. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.griaule.com/configuracao-do-gbds/target-biografico.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.