Camunda 8 deep dive: human tasks, forms and approval authority
Build human review with explicit assignment, versioned forms, validated completion, escalation and permission checks.
Prepared on 20 Oct 2026 for editorial review. Product specifications and company research results are not asserted unless verified.
1. Select the supported task implementation
Camunda user-task implementations and Tasklist APIs vary by release. Confirm whether your environment uses the current Camunda user task or a legacy job-worker-based implementation and follow that version’s lifecycle, form and assignment documentation. Do not assume a tutorial written for one implementation applies unchanged to another.
For an illustrative Review request activity, define the business owner, reviewers, allowed outcomes and evidence needed for a decision. Keep the business approval policy distinct from the diagram’s assignment settings.
2. Bind a deliberate form version
Create a form displaying requestId and the relevant request evidence, with explicit approve or reject outcomes and a reason field where required. Decide which fields are editable and use a form binding supported by your deployment. Promote the reviewed form with the matching process release rather than relying on an uncontrolled latest version.
Form validation improves interaction but is not a security boundary. Validate required values and permitted transitions in the authorised completion path or the application controlling it. Never trust an editable approved flag as independent proof that the caller had approval authority.
3. Test assignments and actual access
Configure assignee, candidate users or candidate groups according to the intended lifecycle and your Tasklist version. Candidate assignment and task visibility depend on the implementation and access configuration; they are not by themselves a complete authorisation policy.
Verify with a reviewer, an unrelated user and a user whose access was revoked. Check who can view evidence, claim work, reassign it and complete it, including direct API requests where an application exposes completion. Keep machine access and human access separately scoped.
4. Model deadlines and separation of duties
Use a due date for agreed scheduling information and a BPMN timer for a deliberate reminder or escalation path. Choose whether the timer interrupts review. A non-interrupting reminder can produce parallel work, so ensure a reminder does not independently authorise the request.
Where separation of duties is required, enforce that the requester cannot approve their own request in an authoritative policy check. Candidate-group labels alone do not establish that rule. For multi-step approvals, record each decision and define how rejections, changed evidence and resubmissions invalidate earlier approval.
5. Handle completion races and audit evidence
Two reviewers can act on the same task near-simultaneously. Handle the supported API’s conflict or already-completed response and refresh the task state rather than presenting both actions as successful. Restrict output mappings so completion cannot unexpectedly overwrite unrelated process variables.
Retain the authenticated actor, decision, reason and referenced evidence version according to the organisation’s retention policy. Process variables should not become an uncontrolled document store; use protected document references and minimise personal data in logs and incident tickets.
6. Run the approval exercise
Complete one approval and one rejection, then try missing required data, an unauthorised reviewer, a revoked user and concurrent completion. Trigger the escalation path in a sandbox and confirm the intended task state and downstream route.
Inspect the resulting process variables and audit evidence, not merely a closed Tasklist entry. Screens, API names and authorisation capabilities must be checked against the installed version before adopting the exercise in a real application.