diff --git a/components/engine/engine-bpm-flowable/src/main/java/org/eclipse/dirigible/components/engine/bpm/flowable/delegate/ResilientClassDelegateFactory.java b/components/engine/engine-bpm-flowable/src/main/java/org/eclipse/dirigible/components/engine/bpm/flowable/delegate/ResilientClassDelegateFactory.java
index dca8a7f42e1..ba35344eaa8 100644
--- a/components/engine/engine-bpm-flowable/src/main/java/org/eclipse/dirigible/components/engine/bpm/flowable/delegate/ResilientClassDelegateFactory.java
+++ b/components/engine/engine-bpm-flowable/src/main/java/org/eclipse/dirigible/components/engine/bpm/flowable/delegate/ResilientClassDelegateFactory.java
@@ -21,7 +21,7 @@
  * Creates {@link ResilientClassDelegate}s for every {@code flowable:class} service task (the shape
  * of Flowable's own {@code DefaultClassDelegateFactory}), so the intent DSL's {@code onError} error
  * routing has its conversion hook on the one path all {@code delegate:} steps run through. Wired
- * into the engine by {@code BpmFlowableConfig} via a {@code DefaultActivityBehaviorFactory}
+ * into the engine by {@code BpmFlowableConfig} via a {@code ResilientActivityBehaviorFactory}
  * carrying this factory.
  */
 public class ResilientClassDelegateFactory implements ClassDelegateFactory {
diff --git a/components/engine/engine-intent/CLAUDE.md b/components/engine/engine-intent/CLAUDE.md
index d2f9bc884c3..4b256842f50 100644
--- a/components/engine/engine-intent/CLAUDE.md
+++ b/components/engine/engine-intent/CLAUDE.md
@@ -413,7 +413,7 @@ Semantics worth knowing:
 - **`abortOn:` on a process = cancel the in-flight instance when the document transitions into a terminal status (BPM events wave 2).** `abortOn: { status: [4, 5], then: markVoid }` — a `-transitioned` of the trigger entity into any listed EntityStatus seed id cancels the whole running instance (pending user tasks, parked waits, armed boundary timers). Emitted as an **interrupting message event subprocess** (`<subProcess triggeredByEvent="true">` with an `isInterrupting="true"` message start on `<Process>Abort` → optional cleanup serviceTask → `terminateEventDefinition`), NOT by wrapping the main flow — chosen over the proposal's subProcess-wrap sketch because it needs no restructuring of the flat step layout and still kills everything in scope. Glue: `ProcessAbortSupport` → the `aborts` collection in `.glue` → `Abort.java.template` — a `MessageHandler` on the entity's `-transitioned` topic (the channel transitions/setters already publish) that matches the status list (`entity.<StatusFk> == <id> || …`) and correlates `<Process>Abort` on the instance THIS process stamped in `ProcessIds` (`ProcessStamps.idFor`, falling back to `ProcessId` for records stamped before that column existed), fail-soft. `then:` omitted or `end` = terminate; a declared `serviceTask` cleanup (setField/setRelationField) is **abort-only** — `BpmnIntentGenerator` filters it out of the main linear chain (`steps.removeIf`) and re-emits it inside the event subprocess (its setter glue is still generated by `SetFieldSupport`). Parser (`validateAbortOn`): integer `status` (scalar or list), trigger entity with a `function: EntityStatus` relation, `then` = `end`/a setField-setRelationField serviceTask that is NOT explicitly routed to from the main flow (`next`/`then`/`else`). DI: the event subprocess is a fixed-placement container box below the main lane (BPMN-2.0 expanded-subprocess children carry absolute plane coordinates). Requested/shaped in upstream discussion #6340. **Consumers:** the orphaned-Inbox-task hole (cancel a SalesOrder mid-confirm), and the structural replacement for a cancelling `expire:` guard (kf quotations drops its `custom/` guard delegate). Caveat: `then` cleanup is one serviceTask (a multi-step cleanup chain is future work).
 - **`whenDeleted: abort | refuse` on a process = what a DELETE of the trigger row does to the in-flight instance (#7074).** `abortOn` is deaf to deletes - a `-deleted` is not a `-transitioned` - so deleting a DRAFT under approval left its Inbox task alive, claimable, opening a form of `—`s and completable over a row that no longer existed. Now EVERY entity-triggered process gets a `<Process>AbortOnDelete` `MessageHandler` on the trigger entity's `-deleted` topic (`deleteAborts` glue collection, `AbortOnDelete.java.template`, the pipeline's collection case) that reads its own `ProcessIds` stamp off the deleted payload and `Process.cancel`s the instance if `Process.isRunning` - generated whatever `whenDeleted` says, because `refuse` guards only the REST surface and a cascade or a reaction still deletes rows. `refuse` lands on the trigger entity as the `processDeleteGuards` scalar (`<Process>:<label>` pairs, an `.edm` attribute like `immutableStatusValues`) and ALL THREE controller templates - power, personal (`my`), partner - answer 409 while the stamped instance runs (the personal surface was missed at first: #7136). `Process.isRunning` / `BpmFacade.isProcessRunning` are new sdk surface (a runtime `ProcessInstanceQuery`, tenant-scoped). Parser: `validateWhenDeleted` (closed vocabulary, needs an entity trigger). Unit: `WhenDeletedIntentTest`, `GlueAbortsTest`, `EdmIntentGeneratorTest`.
 - **`whenMasterDeleted: cascade | refuse` on a composition relation = what a DELETE of the MASTER does to the children it owns (#7100).** Deleting a header left its lines behind: rows pointing at an id that no longer exists, invisible in the UI (no parent page renders them) and still counted by every report and roll-up over the child - a vacation request's deletion left its five days charging the entitlement, which stayed EXHAUSTED. The cascade is emitted for EVERY composition master, intent-authored or hand-authored `.edm`, because it is what composition MEANS: `CompositionChildren.annotate` (ide-template) builds the reverse index the model does not carry - the edge is authored on the CHILD, from which `ModelParameterProcessor` derived `masterEntity`/`masterEntityId` - and the DAO template's `deleteOwnedChildren(id)` runs at the head of `delete`/`deleteById`, deleting each child through ITS OWN repository so the child's `-deleted` event, history trail and its own cascade all run (a deep chain unwinds level by level; a `Store`/SQL delete would silently skip all of it). `refuse` is the author's alternative: it rides the child's composition property as `relationshipMasterDeleteRefused` (an `.edm` attribute, absent = cascade, so an untouched model is byte-identical) and the same method throws `ValidationException` naming both entities - 400 with the message, like every other repository-enforced refusal (`checks:`, the lifecycle graph), NOT the controller-side 409 the process `whenDeleted: refuse` answers, because the enforcement has to hold for a reaction and a cascade too. Parser: `validateWhenMasterDeleted` (closed vocabulary; refused on a non-composition, and on a SECOND composition, which the EDM emits as a plain association and would silently drop). Unit: `WhenMasterDeletedIntentTest`, `CompositionChildrenTest`, `EdmIntentGeneratorTest`; IT: `IntentEmissionCoverageIT`.
-- **Step resilience on a `delegate:` or a `notify:` service task: `retry:` / `onError:` / `{error}` / `vars:` + `produces:`/`uses:`/`clearAfter` (#6762, widened to the send by #7056).** The step vocabulary can now say what happens when a delegate FAILS. `retry: { count: <n>, every: <ISO-8601 duration> }` re-attempts the step `count` further times — emitted as `<flowable:failedJobRetryTimeCycle>R<count+1>/<every></flowable:failedJobRetryTimeCycle>` on the (already `flowable:async`) task; **`R<n>` counts TOTAL attempts** (verified against Flowable's `JobRetryCmd`: first failure sets retries `n-1`, dead-letter when `<= 1`), hence the `+1`. `onError: <step | end>` routes the exhausted (or, with no retry, the first) failure like a decision branch: one `<error id="intentStepError" errorCode="INTENT_STEP_FAILED">` per declaring process plus a cancelling `<boundaryEvent id="<step>Error">` with an `errorEventDefinition`, flow + DI mirroring the boundary timers (`BoundaryError` next to `BoundaryTimer`; `ProcessParallelSupport.routingTargets` includes the target so region walks and `{error}` reachability agree). **The runtime half lives in `engine-bpm-flowable`** — an error boundary only fires on a `BpmnError`, and a delegate's `RuntimeException` is a job failure (rollback → retry → dead-letter), so `ResilientClassDelegateFactory` (wired via `config.setActivityBehaviorFactory(new DefaultActivityBehaviorFactory(...))`) runs every `flowable:class` task through a `ClassDelegate` subclass whose `IntentStepResilience.convertFinalFailure` — only when the task carries a boundary catching `INTENT_STEP_FAILED`, and only on the FINAL attempt (mirroring `JobRetryCmd`'s arithmetic — unit-pinned, and proven against a live engine in `ResilientClassDelegateEngineTest`; the executing job must be looked up via `findJobsByProcessInstanceId` + element/execution match — `findJobsByExecutionId` does NOT surface the very job being executed, which made every first failure look final) — publishes the failure message as the **`__errorMessage`** process variable and calls `ErrorPropagation.propagateError` (a `BpmnError` commits, so the variable persists; the failed attempt's partial writes commit with it — the same property every BPMN error boundary has). The error code and variable name are **string contracts** between `ProcessResilienceSupport` (engine-intent) and `IntentStepResilience` (engine-bpm-flowable), like the `${JavaTask}` literal — no module dependency. `{error}` is a whole-value `setField` `value:` token reading that variable (the `setters` glue entry gains `errorMessage: "true"`, `SetField.java.template` branches on it); the parser rejects it on any step not reachable from an `onError` route, and a partial-value use. **The second hook, and the send (#7056).** v1 was delegate-only because the conversion covered only the `flowable:class` path: the `${JavaTask}`/`${JSTask}` delegateExpression dispatchers never pass through `ClassDelegate`, so a `notify:` step — whose generated sender *does* fail the task on a delivery error, on purpose — was the one step in a process whose failure had nowhere to go. Ordered where it reads most naturally (before the terminal status write) an SMTP blink then left a record whose real work completed sitting in its in-progress status with no message and no failure status, because the incident is on the JOB, not the record; the workaround, making the send the last step, constrained process design for a reason unrelated to the domain. Flowable exposes no `ClassDelegateFactory` analogue for that path, so the hook is the overridable factory method itself: **`ResilientActivityBehaviorFactory`** (now what `BpmFlowableConfig` configures, still carrying `ResilientClassDelegateFactory`) overrides `createServiceTaskDelegateExpressionActivityBehavior` to return a **`ResilientServiceTaskDelegateExpressionActivityBehavior`**, which wraps the single `protected handleException` the superclass funnels `execute` / `trigger` / the future-delegate completion through. **Wrapping rather than re-implementing the catch is the whole design**: the superclass propagates a `BpmnError` the delegate raised itself and applies any `flowable:mapException` on its own, and only *rethrows* a plain unmapped failure — which is exactly the predicate `ResilientClassDelegate` relies on, so `IntentStepResilience` needed no change at all (same signature, same `INTENT_STEP_FAILED` / `__errorMessage` contracts, same `JobRetryCmd` arithmetic). Both dispatchers are covered, which is wider than the DSL lets anyone ask for and deliberately harmless: the conversion fires only on a task carrying the generated boundary. Emission-side the only addition is the cycle on the `${JavaTask}` element, written into the extensionElements block the `handler` field already opens (`appendServiceTask`); the `<error>`, the boundary, its flow and its DI were already shape-agnostic (`collectBoundaryErrors` walks any step declaring `onError`). **A send keeps its async boundary** — the `synchronousNodes` / `completingTransactionNodes` walk strips it only from check-gated setters and the decisions on the way to them, and stops at any other step — which is what makes a cycle on it re-run anything at all. **Three refusals, each because the declaration would otherwise be authored and inert**: a `setField`/`setRelationField` step (a check-gated status write is refused *synchronously* to the person who acted — #7014/#7063 — so routing it away would take the 400 out of the Inbox, and re-attempting a deterministic refusal recovers nothing), a `call:` step and the bare `custom.<Step>` fallback (not covered; bind the handler with `delegate:`), and a **fan-out** send (`notify.forEach`), which is per-row fail-soft by construction and therefore never fails the task — its outcome is observed with `outcome:` + `event: { onNotifyFailed: <Entity> }` (#7023) instead. The generated sender's exception message also gained its cause (`... process: <cause>`), since that string is verbatim what an `onError` route records through `{error}`. Runtime coverage is the delegate test's twin, `ResilientServiceTaskDelegateExpressionEngineTest` — a real engine, delegates registered through `setBeans`, and a third case the wrapper is responsible for: a delegate raising its OWN `BpmnError` still reaches its own boundary. `vars:` declares step data (`[{ name, clearAfter? }]`, plain identifiers): `produces:`/`uses:` on a step must name declared vars (undeclared = parse error — the delegate still sets/reads the process variable itself; the declaration is the contract), and `clearAfter: <serviceTask/userTask step>` emits an `event="end"` execution listener `${execution.removeVariable('<var>')}` on that step's element, so a generated credential does not survive in the instance data or its history (Flowable deletes the historic variable with the runtime one) — cleared on NORMAL completion only; an error route out of the producing step leaves it until instance end. `abortOn.then`'s abort-only check treats `onError` as a main-flow route (a boundary flow into a removed cleanup step would dangle). Absent keys are byte-identical — `ResilienceBpmnTest.anIntentWithoutResilienceKeysEmitsNoneOfIt` pins it. Covered by `StepResilienceIntentTest` + `ProcessVarsIntentTest` (parser), `ResilienceBpmnTest` + `GlueSettersTest` (emission), `IntentStepResilienceTest` (the finality arithmetic), `IntentResilienceBpmnContractTest` (both emitted shapes against the real Flowable converter), `ResilientClassDelegateEngineTest` + `ResilientServiceTaskDelegateExpressionEngineTest` (the two live-engine conversions), `IntentEngineIT.step_resilience_emits_retry_cycle_error_boundary_clear_listener_and_error_glue` + the parse-rejection test, `IntentEmissionCoverageIT.assertStepResilienceRuntime`, and the `sample-intent-resilience` fixture + `IntentResilienceSampleIT` (the manual walk-through, driven through the browser IDE) — one instance whose flaky delegate succeeds on the exact last declared attempt (`KEY-3`), whose secret is gone from the live instance variables after `clearAfter`, and whose doomed step records the SECOND attempt's message via `{error}`.
+- **Step resilience on a `delegate:` or a `notify:` service task: `retry:` / `onError:` / `{error}` / `vars:` + `produces:`/`uses:`/`clearAfter` (#6762, widened to the send by #7056).** The step vocabulary can now say what happens when a delegate FAILS. `retry: { count: <n>, every: <ISO-8601 duration> }` re-attempts the step `count` further times — emitted as `<flowable:failedJobRetryTimeCycle>R<count+1>/<every></flowable:failedJobRetryTimeCycle>` on the (already `flowable:async`) task; **`R<n>` counts TOTAL attempts** (verified against Flowable's `JobRetryCmd`: first failure sets retries `n-1`, dead-letter when `<= 1`), hence the `+1`. `onError: <step | end>` routes the exhausted (or, with no retry, the first) failure like a decision branch: one `<error id="intentStepError" errorCode="INTENT_STEP_FAILED">` per declaring process plus a cancelling `<boundaryEvent id="<step>Error">` with an `errorEventDefinition`, flow + DI mirroring the boundary timers (`BoundaryError` next to `BoundaryTimer`; `ProcessParallelSupport.routingTargets` includes the target so region walks and `{error}` reachability agree). **The runtime half lives in `engine-bpm-flowable`** — an error boundary only fires on a `BpmnError`, and a delegate's `RuntimeException` is a job failure (rollback → retry → dead-letter), so `ResilientClassDelegateFactory` (wired via `config.setActivityBehaviorFactory(new ResilientActivityBehaviorFactory(new ResilientClassDelegateFactory()))`) runs every `flowable:class` task through a `ClassDelegate` subclass whose `IntentStepResilience.convertFinalFailure` — only when the task carries a boundary catching `INTENT_STEP_FAILED`, and only on the FINAL attempt (mirroring `JobRetryCmd`'s arithmetic — unit-pinned, and proven against a live engine in `ResilientClassDelegateEngineTest`; the executing job must be looked up via `findJobsByProcessInstanceId` + element/execution match — `findJobsByExecutionId` does NOT surface the very job being executed, which made every first failure look final) — publishes the failure message as the **`__errorMessage`** process variable and calls `ErrorPropagation.propagateError` (a `BpmnError` commits, so the variable persists; the failed attempt's partial writes commit with it — the same property every BPMN error boundary has). The error code and variable name are **string contracts** between `ProcessResilienceSupport` (engine-intent) and `IntentStepResilience` (engine-bpm-flowable), like the `${JavaTask}` literal — no module dependency. `{error}` is a whole-value `setField` `value:` token reading that variable (the `setters` glue entry gains `errorMessage: "true"`, `SetField.java.template` branches on it); the parser rejects it on any step not reachable from an `onError` route, and a partial-value use. **The second hook, and the send (#7056).** v1 was delegate-only because the conversion covered only the `flowable:class` path: the `${JavaTask}`/`${JSTask}` delegateExpression dispatchers never pass through `ClassDelegate`, so a `notify:` step — whose generated sender *does* fail the task on a delivery error, on purpose — was the one step in a process whose failure had nowhere to go. Ordered where it reads most naturally (before the terminal status write) an SMTP blink then left a record whose real work completed sitting in its in-progress status with no message and no failure status, because the incident is on the JOB, not the record; the workaround, making the send the last step, constrained process design for a reason unrelated to the domain. Flowable exposes no `ClassDelegateFactory` analogue for that path, so the hook is the overridable factory method itself: **`ResilientActivityBehaviorFactory`** (now what `BpmFlowableConfig` configures, still carrying `ResilientClassDelegateFactory`) overrides `createServiceTaskDelegateExpressionActivityBehavior` to return a **`ResilientServiceTaskDelegateExpressionActivityBehavior`**, which wraps the single `protected handleException` the superclass funnels `execute` / `trigger` / the future-delegate completion through. **Wrapping rather than re-implementing the catch is the whole design**: the superclass propagates a `BpmnError` the delegate raised itself and applies any `flowable:mapException` on its own, and only *rethrows* a plain unmapped failure — which is exactly the predicate `ResilientClassDelegate` relies on, so `IntentStepResilience` needed no change at all (same signature, same `INTENT_STEP_FAILED` / `__errorMessage` contracts, same `JobRetryCmd` arithmetic). Both dispatchers are covered, which is wider than the DSL lets anyone ask for and deliberately harmless: the conversion fires only on a task carrying the generated boundary. Emission-side the only addition is the cycle on the `${JavaTask}` element, written into the extensionElements block the `handler` field already opens (`appendServiceTask`); the `<error>`, the boundary, its flow and its DI were already shape-agnostic (`collectBoundaryErrors` walks any step declaring `onError`). **A send keeps its async boundary** — the `synchronousNodes` / `completingTransactionNodes` walk strips it only from check-gated setters and the decisions on the way to them, and stops at any other step — which is what makes a cycle on it re-run anything at all. **Three refusals, each because the declaration would otherwise be authored and inert**: a `setField`/`setRelationField` step (a check-gated status write is refused *synchronously* to the person who acted — #7014/#7063 — so routing it away would take the 400 out of the Inbox, and re-attempting a deterministic refusal recovers nothing), a `call:` step and the bare `custom.<Step>` fallback (not covered; bind the handler with `delegate:`), and a **fan-out** send (`notify.forEach`), which is per-row fail-soft by construction and therefore never fails the task — its outcome is observed with `outcome:` + `event: { onNotifyFailed: <Entity> }` (#7023) instead. The generated sender's exception message also gained its cause (`... process: <cause>`), since that string is verbatim what an `onError` route records through `{error}`. Runtime coverage is the delegate test's twin, `ResilientServiceTaskDelegateExpressionEngineTest` — a real engine, delegates registered through `setBeans`, and a third case the wrapper is responsible for: a delegate raising its OWN `BpmnError` still reaches its own boundary. `vars:` declares step data (`[{ name, clearAfter? }]`, plain identifiers): `produces:`/`uses:` on a step must name declared vars (undeclared = parse error — the delegate still sets/reads the process variable itself; the declaration is the contract), and `clearAfter: <serviceTask/userTask step>` emits an `event="end"` execution listener `${execution.removeVariable('<var>')}` on that step's element, so a generated credential does not survive in the instance data or its history (Flowable deletes the historic variable with the runtime one) — cleared on NORMAL completion only; an error route out of the producing step leaves it until instance end. `abortOn.then`'s abort-only check treats `onError` as a main-flow route (a boundary flow into a removed cleanup step would dangle). Absent keys are byte-identical — `ResilienceBpmnTest.anIntentWithoutResilienceKeysEmitsNoneOfIt` pins it. Covered by `StepResilienceIntentTest` + `ProcessVarsIntentTest` (parser), `ResilienceBpmnTest` + `GlueSettersTest` (emission), `IntentStepResilienceTest` (the finality arithmetic), `IntentResilienceBpmnContractTest` (both emitted shapes against the real Flowable converter), `ResilientClassDelegateEngineTest` + `ResilientServiceTaskDelegateExpressionEngineTest` (the two live-engine conversions), `IntentEngineIT.step_resilience_emits_retry_cycle_error_boundary_clear_listener_and_error_glue` + the parse-rejection test, `IntentEmissionCoverageIT.assertStepResilienceRuntime`, and the `sample-intent-resilience` fixture + `IntentResilienceSampleIT` (the manual walk-through, driven through the browser IDE) — one instance whose flaky delegate succeeds on the exact last declared attempt (`KEY-3`), whose secret is gone from the live instance variables after `clearAfter`, and whose doomed step records the SECOND attempt's message via `{error}`.
 - **`kind: parallel` = concurrent branches (fork/join), and a branch is a CHAIN.** `- { name: reviews, kind: parallel, args: { branches: [techReview, commercial], next: consolidate } }` emits a **parallel gateway pair**: the fork step itself (diverging) fans an unconditioned flow to each branch, and a synthesized converging `<fork>Join` waits for all of them before the single flow on to `next`. A **branch is everything reachable from the branch step through its own routing** — its `next`, a decision's `then`/`else`, a boundary `timeout`/`expire` branch, and a **nested `parallel`** with its own fork/join pair (#6568; #6556 shipped the single-step-branch v1). That reachable set is the branch **region** (`ProcessParallelSupport.regions`, walked once and shared with the parser so validation and emission cannot drift), and the whole region — like a decision's targets — is **off the linear chain**, so declaration order is irrelevant and `BpmnIntentGenerator.branchChainFlows` wires it explicitly. Inside a region there is deliberately **no positional fall-through**: a step routes explicitly, or — declaring no routing at all — is a branch **terminal** and flows into the join; the routing literal **`join`** converges on the innermost enclosing join, which is what lets a decision inside a branch rejoin from both arms (`else: join`) and what a nested fork does implicitly when it omits `next`. Parser (`validateParallelSteps` + `validateParallelRouting`): ≥2 distinct branches, no self-branch, `join` only inside a region and never a step NAME, no `end` inside a region (the join would wait forever for a token that ended), no step in two branches (two tokens would run it twice and still leave the join waiting), nothing outside a region routing into one — which is also how "a branch routed to the fork's own `next` instead of converging on `join`" surfaces; a top-level fork still requires `next`, a nested one may omit it. **The entry/exit mapping is the subtle part:** `augmentWithResolvers` inserts delegates around a step (a resolver/field/timer loader before, the writer/setter after), and off the linear chain nothing connects by adjacency any more — so a flow INTO a region step lands on its first inserted node and a flow OUT of it leaves from its last (`TargetResolver.entry`/`exit`; the branch's `next` rides on the writer, exactly as on the main chain). Covered by `ParallelBranchChainTest` (emission, against the real generator), `ProcessParallelSupportTest` (the region walk) and `IntentEngineIT.parallel_branches_chain_onward_and_nest`.
 - **`init: <seed id>` on a to-one relation = the FK's DB-level default (`RelationIntent.init` → `dataDefaultValue` on the FK property, in both `relationProperty` and `crossModelRelationProperty`).** The relation analogue of a field's `defaultValue`; a new row gets this FK on insert when the column is left unset (e.g. `Status` defaults to the DRAFT seed, `PaymentMethod` to Bank, `SentMethod` to E-mail). **Use `init` for an INITIAL status, never a process step.** A DB default is applied at insert — atomic, no ordering to reason about — while a start-step setter is extra moving parts for the same effect. (Since #7104 the generated repository also assigns the default itself, before the create-time calculations run, so a calculation reading a defaulted column no longer sees the null the DB was about to fill — the DB DEFAULT remains for every write that does not go through the repository.) (Historical note: a start-step `setRelationField` also used to be *clobbered* by the trigger's `ProcessId` write-back, which was a full-row `updateWithoutEvent` merge of a stale snapshot — confirmed live: the invoice reached the Approve task but `Status` stayed null. The trigger now persists `ProcessId` via the targeted single-column `repository.updateProperty(...)` (SDK `JavaRepository`/`JavaEntityStore`), and a minted business key the same way before the start, so that race is gone; `init:` remains the right modeling for an initial status.) `setRelationField` is for *transitions* (after a user task / on a decision branch).
 - **`trigger: { onCreate|onUpdate|onDelete: <Entity>, when: "<expr>" }` starts the process on the named `<Entity>` lifecycle event** - fully wired (Java). Any of the three events is supported: `onCreate` binds the entity's base topic, `onUpdate`/`onDelete` the `-updated`/`-deleted` topics the Java DAO publishes (`TriggerSupport` + `EventBinding`); an optional `when` guard (a single `field ==|!= literal`, via `NotificationSupport.guard`) gates `Process.start`. Three parts: (1) the parser validates at most one event kind and that the target is a declared entity; (2) the EDM generator adds a `ProcessId` back-reference property (VARCHAR) plus the per-process `ProcessIds` stamps column (VARCHAR, `Process=instanceId` pairs) to that entity and a `triggers` collection to the `.model` (`TriggerSupport` + `EdmIntentGenerator.buildTriggers`); (3) the **`template-application-events-java`** template (intent-driven, like the other language templates) reads that `triggers` collection and emits one **`gen/events/<module>/<Process>Trigger.java`** per trigger - a client-Java self-describing `MessageHandler` (a `@Component` whose `destination()` is the entity's per-operation topic via `topicSuffix` and whose `kind()` is `TOPIC`) that loads the entity, applies the `when` guard, calls `Process.start(<process>, businessKey, <locators JSON>)`, and writes the instance id back to `ProcessIds` against its own process name plus `ProcessId` (so THIS process starts at most once - one `ProcessId` cannot say WHICH process ran, and reading it as "some process ran" silently skipped every follow-up flow on an already-stamped record, #6862). **The write-back is crash-safe by construction (#6815):** the per-process stamp in `ProcessIds` IS the at-most-once guard while the start and the write-back commit independently, so everything that can precede the start does — the minted business key is persisted first, and every process variable (the `__entityUrl`/`__entityId` locators, the FK locators, `__personalUser`) rides the start payload instead of a post-start `setVariable` (all are known up front, and a wait-state-less process finishes inside `start`, where a `setVariable` would then throw). The one remaining post-start step is the targeted `updateProperties` of both process columns at once (a record carrying one without the other is either invisible to the task UI or blocked from ever starting the flow again), which a `checks:` gate can no longer refuse (the generated repository runs `enforceChecks` only for a write that touches an **authored** column - a gate has no opinion about which process handles the document, and by then the instance is running), a swallowed start (`null` id) is logged rather than written, and if the write still does not land — the row was deleted meanwhile, or it threw — the instance is **cancelled** (`Process.cancel`) and the failure re-thrown, rather than left running with nothing pointing at it. The Java DAO template (`template-application-dao-java`) now publishes the create event (`Producer.sendToTopic('${projectName}-${perspectiveName}-${name}', json)`) the way the TS DAO does - that's the topic the handler binds to. `gen/events/<module>` (the `<module>` segment = the sanitized intent name, `IntentNaming.javaModule`) is a sibling of `gen/<model>`, so it survives the per-model regeneration wipe. The events template iterates the model's `triggers` via a new **`triggers` collection case in the generation pipeline's `ModelGenerator`** (the engine's collection switch is hardcoded; the case has its own loop because triggers are not entity-shaped). The BPM **business key** defaults to the entity's primary key but is **configurable**: `trigger: { ..., businessKey: <field> }` names which trigger-entity field becomes the started instance's business key (the listener still loads the entity by its PK via `findById`; only the business key differs — a separate `businessKeyProperty` in `.glue`). An optional `businessKeyStrategy: timestamp` mints a `yyyyMMddHHmmss` value into that field when it is blank and persists it via the listener's existing update — the simple "for now" generator and the **extension point** for richer pluggable number generators later (sequential, zero-padded, config-prefixed invoice numbers); the parser validates the field exists, the strategy is supported, and (for `timestamp`) the field is `string`/`text`. `TriggerSupport.triggerBusinessKey`/`triggerBusinessKeyStrategy` read them; `GlueIntentGenerator` emits `businessKeyProperty` + `generateBusinessKey`; `Trigger.java.template` renders the mint-if-blank block. `onSchedule` is still unmodelled. **Casing subtlety in the generated handler:** its `import gen.<genFolder>.data.<perspective>.<Entity>{Entity,Repository}` must use the **lowercased** Java package segment (`javaPerspective` = `sanitizeJavaIdentifier(perspective)`, matching the DAO/entity templates' `javaPerspectiveName` folder), while the `destination()` topic (`"<project>-<perspective>-<entity>"`) keeps the **raw** perspective so it matches the topic the DAO publishes to (`${projectName}-${perspectiveName}-${name}`). The `triggers` collection case in the pipeline supplies both (`javaPerspective` for the import, `perspective` for the topic). Using the raw perspective in the import compiled on macOS (case-insensitive FS) but failed `javac` with "package gen.x.data.Member does not exist" because the entity files declare the lowercased package.
diff --git a/components/engine/engine-intent/src/main/java/org/eclipse/dirigible/components/intent/parser/IntentParser.java b/components/engine/engine-intent/src/main/java/org/eclipse/dirigible/components/intent/parser/IntentParser.java
index a5cd5a5ed5c..765d9f93a30 100644
--- a/components/engine/engine-intent/src/main/java/org/eclipse/dirigible/components/intent/parser/IntentParser.java
+++ b/components/engine/engine-intent/src/main/java/org/eclipse/dirigible/components/intent/parser/IntentParser.java
@@ -6278,9 +6278,15 @@ private static void validateSetFieldSteps(ProcessIntent process, String triggerE
                 }
             }
             String next = stepArg(step, "next");
-            if (next != null && !next.isBlank() && !isRoutingLiteral(next) && !stepNames.contains(next)) {
-                issues.add(
-                        "process [" + process.getName() + "] step [" + step.getName() + "] `next` references unknown step [" + next + "]");
+            if (next != null && !next.isBlank() && !isRoutingLiteral(next)) {
+                if (next.equals(step.getName())) {
+                    // A step whose `next` is itself emits a self-targeting sequence flow the engine spins on.
+                    issues.add("process [" + process.getName() + "] step [" + step.getName()
+                            + "] `next` targets itself - a self-loop that never advances");
+                } else if (!stepNames.contains(next)) {
+                    issues.add("process [" + process.getName() + "] step [" + step.getName() + "] `next` references unknown step [" + next
+                            + "]");
+                }
             }
         }
     }
diff --git a/components/engine/engine-intent/src/test/java/org/eclipse/dirigible/components/intent/generator/ResilienceBpmnTest.java b/components/engine/engine-intent/src/test/java/org/eclipse/dirigible/components/intent/generator/ResilienceBpmnTest.java
index 47ed44ea140..f2579cb4f20 100644
--- a/components/engine/engine-intent/src/test/java/org/eclipse/dirigible/components/intent/generator/ResilienceBpmnTest.java
+++ b/components/engine/engine-intent/src/test/java/org/eclipse/dirigible/components/intent/generator/ResilienceBpmnTest.java
@@ -78,7 +78,10 @@ class ResilienceBpmnTest {
             "      - { name: notifyOwner, kind: serviceTask, args: { notify: { to: owner@example.com, subject: \"Tenant provisioned\","
                     + " body: \"Ready.\" }, retry: { count: 1, every: PT5S }, onError: recordFailure, next: done } }\n"
                     + "      - { name: recordFailure,")
-                                                .replace("onError: recordFailure, next: done", "onError: recordFailure, next: notifyOwner");
+                                                // Rewire only provisionApp (its PT1M cycle is unique) to lead to the send; the send keeps
+                                                // its own next: done, so the chain is provisionApp -> notifyOwner -> done, not a self-loop.
+                                                .replace("every: PT1M }, onError: recordFailure, next: done",
+                                                        "every: PT1M }, onError: recordFailure, next: notifyOwner");
 
     private static String bpmn(String yaml) {
         IntentModel model = IntentParser.parse(yaml);
@@ -247,6 +250,10 @@ void aSendStepGetsItsOwnErrorBoundaryAndRoute() {
         assertTrue(bpmn.contains("<boundaryEvent id=\"notifyOwnerError\" attachedToRef=\"notifyOwner\" cancelActivity=\"true\">"),
                 "the send needs its own cancelling boundary in:\n" + bpmn);
         assertFlow(bpmn, "notifyOwnerError", "recordFailure");
+        // The normal chain is provisionApp -> notifyOwner -> done (the end step, emitted as "end"): the
+        // send advances, never loops to itself.
+        assertFlow(bpmn, "provisionApp", "notifyOwner");
+        assertFlow(bpmn, "notifyOwner", "end");
         assertTrue(bpmn.contains("BPMNShape_notifyOwnerError"), "the boundary needs a shape or the modeler opens broken:\n" + bpmn);
         assertTrue(bpmn.contains("BPMNEdge_flow_notifyOwnerError_then"), "the error route needs its edge:\n" + bpmn);
     }
@@ -254,8 +261,7 @@ void aSendStepGetsItsOwnErrorBoundaryAndRoute() {
     /** A send that declares nothing emits no cycle - the send path stays byte-identical too. */
     @Test
     void aSendWithoutResilienceKeysEmitsNoCycle() {
-        String bpmn = bpmn(SEND_YAML.replace("retry: { count: 1, every: PT5S }, onError: notifyOwner, ", "")
-                                    .replace("retry: { count: 1, every: PT5S }, onError: recordFailure, ", ""));
+        String bpmn = bpmn(SEND_YAML.replace("retry: { count: 1, every: PT5S }, onError: recordFailure, ", ""));
 
         int task = bpmn.indexOf("<serviceTask id=\"notifyOwner\"");
         int nextTask = bpmn.indexOf("<serviceTask id=\"recordFailure\"");
diff --git a/components/engine/engine-intent/src/test/java/org/eclipse/dirigible/components/intent/parser/StepResilienceIntentTest.java b/components/engine/engine-intent/src/test/java/org/eclipse/dirigible/components/intent/parser/StepResilienceIntentTest.java
index 40d501fbc0d..c1b163a2185 100644
--- a/components/engine/engine-intent/src/test/java/org/eclipse/dirigible/components/intent/parser/StepResilienceIntentTest.java
+++ b/components/engine/engine-intent/src/test/java/org/eclipse/dirigible/components/intent/parser/StepResilienceIntentTest.java
@@ -103,6 +103,17 @@ void anUnknownOnErrorTargetIsRejected() {
         assertTrue(issue.contains("step [createSchema]"), "the message must locate the step: " + issue);
     }
 
+    /**
+     * A step whose {@code next} names itself would emit a self-targeting sequence flow the engine spins
+     * on; it names an existing step, so only a dedicated check catches it (dirigible #7226).
+     */
+    @Test
+    void aNextTargetingItselfIsRejected() {
+        String issue = assertIssue(YAML.replace("onError: recordFailure, next: done", "onError: recordFailure, next: provisionApp"),
+                "`next` targets itself - a self-loop that never advances");
+        assertTrue(issue.contains("step [provisionApp]"), "the message must locate the step: " + issue);
+    }
+
     /** The literal `end` routes the failure to the process end, like a decision branch. */
     @Test
     void onErrorMayRouteToEnd() {