> ## 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.

# Revisió de 4 ulls: aprovació maker/checker

> Didit exigeix que un segon responsable aprovi o rebutgi cada resolució; el resultat proposat queda pendent fins que ho validi un altre revisor.

La revisió a 4 ulls afegeix una segona aprovació independent abans que una resolució tingui efecte, un control estàndard de separació de funcions per a les investigacions de major risc.

***

## Configuració

Al blueprint creador, estableix **Revisió a 4 ulls** com a **blueprint revisor**. Establir aquest camp és el que activa la revisió a 4 ulls per al blueprint creador; no hi ha cap interruptor separat.

## Com funciona

1. Un responsable del blueprint creador resol un cas com de costum (fals positiu o amenaça vàlida, i una nota si cal).
2. En lloc de tancar-lo, l'estat del cas es manté en **Obert**, la resolució proposada queda preparada i el cas passa a la cua del **blueprint revisor**. La línia de temps del cas registra `Submitted for approval`.
3. Un revisor revisa la pestanya Visió general del cas, on un bàner de control dual mostra les accions **Aprovar** i **Rebutjar**.
4. **Aprovar** aplica la resolució preparada: el cas passa a **Resolt** amb la resolució i la nota originals, atribuït al responsable que l'ha enviat. La línia de temps registra `Approval granted` i després `Resolved`.
5. **Rebutjar** esborra la resolució preparada i torna el cas al **blueprint creador**. La línia de temps registra `Approval rejected`, i el creador rep una notificació.

> [!WARNING]
>
> El responsable que ha enviat la resolució no pot aprovar-la ni rebutjar-la ell mateix, i això es fa complir al servidor. Si ho intenta, es retorna un 403. (Aprovar o rebutjar un cas sense cap resolució pendent d'aprovació retorna un 409.)

## Com s'anomena el revisor

El responsable que resol pot indicar el membre que ha d'aprovar la resolució, amb el camp `checker` de l'[API per resoldre un cas](https://docs.didit.me/ca/management-api/cases/resolve.md).
Només aquest membre pot aprovar-la o rebutjar-la; qualsevol altre, inclosa una clau d'API, rep un 403.
El camp `checker` del cas mostra el membre indicat fins que la resolució s'aprovi, es rebutgi o el cas es retorni per a una nova revisió.
Si no s'indica cap revisor, la resolució espera a la cua del blueprint revisor, tal com s'ha descrit anteriorment.
El revisor indicat ha de tenir accés al cas de l'aplicació i no pot ser el responsable que ha enviat la resolució.

## Quan canvien les evidències

Si es canvia la resposta d'una llista de verificació o si s'afegeix o s'elimina una verificació o una transacció vinculada, es cancel·la la decisió pendent i el cas torna a la seva política de revisió original.
La línia de temps d'activitat registra que cal una nova decisió de revisió i conserva la proposta anterior en l'esdeveniment d'auditoria.
El revisor ha d'examinar les evidències actualitzades i enviar una nova decisió abans que un segon responsable pugui aprovar-la.
Repetir la mateixa resposta de la llista de verificació no cancel·la una revisió pendent.

L'aprovació també comprova les evidències d'origen vinculades amb el que es va enviar a revisió.
Un estat de verificació canviat, un camp de document corregit, unes evidències de transacció modificades o una font no disponible bloquegen l'aprovació amb `409`.
Perdre l'accés a les evidències de la xarxa global vinculades mitjançant un Fraud Check també requereix una nova revisió.
Utilitza **Rebutjar** per tornar el cas al blueprint creador, revisar les evidències actualitzades i enviar una nova decisió.
Obrir el registre d'origen o afegir una nota interna al cas no bloqueja per si sol una revisió sense canvis.
Si no es poden verificar les evidències enviades, cal una nova revisió abans de l'aprovació.

## Notes

* Els requisits de revisió es desen quan s'obre el cas.
  Passar a la cua del revisor no substitueix aquests requisits per les modificacions posteriors de la política.
* Un cas només pot tenir una resolució preparada alhora; demanar més informació (**En espera de l'usuari**) queda bloquejat mentre hi hagi una resolució pendent d'aprovació.
* La revisió a 4 ulls es combina amb les [notes de resolució obligatòries](https://docs.didit.me/ca/console/case-management/blueprints.md#configuració-general): activa totes dues opcions per als teus blueprints de major risc perquè es requereixin tant una justificació documentada com un segon revisor.


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