Bewerken: ConfirmationRole (Bevestigingsrol)

Sectie: Tips voor consultants

Reden:

## Tips voor consultants

- **Context scheidt processen**: De `Context` (bitmasker) bepaalt of een rol geldt voor WorkPermit (1), ManagementOfChange (2) of RootCauseAnalysis (4). Houd rollen per context gescheiden om overzicht te bewaren in het ondertekeningsscherm.
- **Holder, Requester en Provider zijn gedragsbepalend**: Deze drie Boolean-velden sturen de schermlogica en workflowrechten. Definieer per implementatie duidelijk wie de houder is (CFMRHOLDER=1), wie aanvraagt en wie uitvoert — dit heeft directe invloed op wie wat mag zien en wijzigen.
- **LastConfirmation als afsluiter**: De rol met `LastConfirmation=1` is de definitieve poort: pas als deze rol heeft ondertekend, wordt de vergunning als volledig beschouwd. Stel slechts één rol in als LastConfirmation per context.
- **AddAutomatically bespaart werk, maar let op scope**: Rollen met `AddAutomatically=1` verschijnen op elke vergunning van de bijbehorende context. Gebruik dit alleen voor rollen die altijd aanwezig moeten zijn (bv. de vergunninghouder), anders ontstaan onnodige blokkeringen.
- **LOTO-statement als aanvulling**: `LockoutTagoutConfirmationStatementAddition` biedt een extra tekstveld voor LOTO-specifieke verklaringen, zonder een aparte rol te hoeven aanmaken. Gebruik dit bij organisaties met een formeel Lockout/Tagout-programma.
- **Order bepaalt volgorde in scherm**: Vul `Order` consequent in om de presentatie in het werkvergunningscherm te sturen — een logische volgorde (aanvrager → houder → uitvoerder → laatste bevestiging) vergroot de gebruiksvriendelijkheid.

---