eho/register-referentie
1
0
Fork 0
Code Issues 10 Pull Requests 1 Actions Packages Projects Releases 1 Wiki Activity

ADR: beoordeling escalation reassigns via external-worker task (S-14) #98

New Issue
Closed
opened 2026-07-17 06:56:57 +00:00 by not · 1 comment
not commented 2026-07-17 06:56:57 +00:00
Contributor
Copy Link
Copy Source

Recorded ahead of S-14 (#15) per CLAUDE.md §14 (non-obvious decision + bends the workflow boundary). ADR file will land as docs/architecture/adr-0015-*.md in the implementing PR.

Decision to be made: How does the 14-day boundary timer on the Beoordelen user task reassign the open task from the behandelaar group to teamlead?

Context / forces: Flowable cannot reassign an already-open user task's candidate group from pure BPMN XML — it needs code. The repo has held a "no custom Java/jars in Flowable; Workflow Client is the only thing that talks to Flowable (§8.2)" posture, and already has an external-worker pattern (topic acquire/complete via REST, see ADR-0009). The task must stay open for the teamlead, so escalation must be non-interrupting.

Options considered:

  1. External-worker escalation task. Non-interrupting boundary timer P14D on Beoordelen → external-worker serviceTask on a new topic (BeoordelingEscaleren) → Workflow Client acquires the job and PUTs the Beoordelen task to swap candidateGroups behandelaar→teamlead, then completes the job. Reuses ADR-0009 machinery; Workflow Client stays the sole Flowable client.
  2. Flowable timer/task listener (delegate). In-engine reassignment via a custom Java listener/jar. Breaks the REST-only posture; adds a build/deploy surface to Flowable.

Proposed option + why: Option 1. It keeps §8.2 intact, reuses the existing external-worker infrastructure, and adds no custom code inside Flowable. Cost is a new topic, a worker loop, and a Workflow Client reassign method — all covered by unit + integration tests.

Consequences: Escalation latency is bounded by the worker poll interval (seconds), acceptable for a 14-day timer. The Workflow Client gains a task-reassign capability reusable by future escalations. Flowable stays a stock image.

Coupling rules touched (CLAUDE.md §8): §8.2 (Workflow Client is the only code that talks to Flowable) — upheld, not bent. The BPMN owns the escalation path; the reassignment is delegated to the Workflow Client via an external task, consistent with §8.2.

Recorded ahead of S-14 (#15) per CLAUDE.md §14 (non-obvious decision + bends the workflow boundary). ADR file will land as `docs/architecture/adr-0015-*.md` in the implementing PR. **Decision to be made:** How does the 14-day boundary timer on the `Beoordelen` user task reassign the open task from the `behandelaar` group to `teamlead`? **Context / forces:** Flowable cannot reassign an already-open user task's candidate group from pure BPMN XML — it needs code. The repo has held a "no custom Java/jars in Flowable; Workflow Client is the only thing that talks to Flowable (§8.2)" posture, and already has an external-worker pattern (topic acquire/complete via REST, see ADR-0009). The task must stay open for the teamlead, so escalation must be non-interrupting. **Options considered:** 1. **External-worker escalation task.** Non-interrupting boundary timer `P14D` on `Beoordelen` → external-worker `serviceTask` on a new topic (`BeoordelingEscaleren`) → Workflow Client acquires the job and PUTs the `Beoordelen` task to swap `candidateGroups` `behandelaar`→`teamlead`, then completes the job. Reuses ADR-0009 machinery; Workflow Client stays the sole Flowable client. 2. **Flowable timer/task listener (delegate).** In-engine reassignment via a custom Java listener/jar. Breaks the REST-only posture; adds a build/deploy surface to Flowable. **Proposed option + why:** Option 1. It keeps §8.2 intact, reuses the existing external-worker infrastructure, and adds no custom code inside Flowable. Cost is a new topic, a worker loop, and a Workflow Client reassign method — all covered by unit + integration tests. **Consequences:** Escalation latency is bounded by the worker poll interval (seconds), acceptable for a 14-day timer. The Workflow Client gains a task-reassign capability reusable by future escalations. Flowable stays a stock image. **Coupling rules touched (CLAUDE.md §8):** §8.2 (Workflow Client is the only code that talks to Flowable) — upheld, not bent. The BPMN owns the escalation path; the reassignment is delegated to the Workflow Client via an external task, consistent with §8.2.
not added the area:workflowtype:adr-proposal labels 2026-07-17 06:56:57 +00:00
not commented 2026-07-17 09:46:30 +00:00
Author
Contributor
Copy Link
Copy Source

Accepted and recorded as docs/architecture/adr-0015-beoordeling-escalation.md, merged in #99 (closes #15). Closing this proposal.

Accepted and recorded as `docs/architecture/adr-0015-beoordeling-escalation.md`, merged in #99 (closes #15). Closing this proposal.
not closed this issue 2026-07-17 09:46:30 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area:acl
area:bff
area:docs
area:domain
area:event-subscriber
area:infra
area:portal-behandel
area:portal-beheer
area:portal-openbaar
area:portal-self-service
area:projection
area:workflow
type:adr-proposal
type:bug
type:chore
type:slice
No labels area:workflow type:adr-proposal
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
eho (Edwin van den Houdt)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: eho/register-referentie#98