--- id: DOM-PFM-INT-006 title: Workflow Action realises: CON-PFM-INT-006 product_area: platform module: integrations revision: 1 status: draft design_intent: confirmed implementation_evidence: observed origin: >- docs/proposals/application-processes-and-workflow-actions/14-decisions.md D-03, D-08, D-10 (taken by Andrew 2026-10-17) source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 macroservice-libraries: 54536a441935c6e09fdb7f96f0bec71c52ba4e03 owned_by: SVC-PFM-INT-workflow-actions lifecycle: - STATE-PFM-INT-015 - STATE-PFM-INT-016 custom_fields: none identity: >- Trigger identity combines its host kind and key; action types have an application-owned key. Customer templates and calendars use configuration identifiers, while shipped templates reserve a system prefix. Rules have numbered versions with at most one draft. attributes: - name: trigger point kind: document required: true computed: false notes: 'A trigger identifies the host moment, supplied facts, contract version and registry standing.' - name: action type kind: document required: true computed: false notes: >- Action declarations specify parameter and output schemas, executor, execution kind, permitted contexts, required authority and supported contract versions. - name: action and workflow templates kind: document required: false computed: false notes: >- Customer and shipped recipes contain an action or stage configuration that is copied into a destination definition. - name: business calendar kind: document required: false computed: false notes: >- Calendars retain zone, working weekdays, optional hours, no more than four hundred holidays and a unique default flag within the workspace. - name: automation rule kind: document required: false computed: false notes: >- A rule retains its event, derived owning application, description, status and current published-version reference. - name: automation rule version kind: collection required: false computed: false notes: >- Versions retain conditions, actions, condition fingerprint, required permissions and publication attribution; published content is immutable. - name: runs and timers kind: collection required: false computed: true notes: >- Shared read-only views combine hosts’ run and timer records, including attention information, without relocating those records. - name: version kind: computed required: true computed: true notes: 'Replacements require the template, calendar or rule version previously read.' relationships: - to: DOM-PFM-INT-005 cardinality: An automation rule’s event should correspond to the application’s business-event declaration. ownership: That relationship joins separate registries and remains unenforced. cross_service: true - to: DOM-PFM-INT-003 cardinality: An action executed by a host can invoke a provider capability through the gateway. ownership: The host owns its action run and the integrations service owns the resulting capability execution. cross_service: true invariants: - id: INV-DOM-PFM-INT-006-01 statement: >- Registry registration requires an active service principal for the application whose declarations it replaces. enforced_at: - service provenance: test source: >- services-platform:modules/workflow-actions/tests/e2e/workflow-actions-registry.e2e.spec.js#answers 403 to another application’s principal registering CRM - id: INV-DOM-PFM-INT-006-02 statement: 'Ownership, host, execution-kind or contract-version conflicts reject the complete registration.' enforced_at: - service provenance: test source: >- services-platform:modules/workflow-actions/tests/integration/services/registry/register-manifest.integration.spec.js#refuses a key another application registered (409) - id: INV-DOM-PFM-INT-006-03 statement: The latest manifest retires entries it omits and restores entries it declares again. enforced_at: - service provenance: test source: >- services-platform:modules/workflow-actions/tests/integration/services/registry/register-manifest.integration.spec.js#retires what is absent, and answers its keys - id: INV-DOM-PFM-INT-006-04 statement: >- Template writes and automation publication validate actions against active types allowed for the chosen host and trigger. enforced_at: - service provenance: test source: >- services-platform:modules/workflow-actions/tests/integration/services/persistence/action-templates.integration.spec.js#refuses a type that is declared and switched off - id: INV-DOM-PFM-INT-006-05 statement: >- Using a template copies its settings into the destination definition, so subsequent template edits do not alter that definition. enforced_at: - service provenance: documented source: >- services-platform:docs/workflow-actions/README.md#Workflow actions: Platform's part of the Workflow Action Engine - id: INV-DOM-PFM-INT-006-06 statement: >- Only one calendar can be default in a workspace; selecting a new default clears the old flag in the same database transaction. enforced_at: - service - database provenance: observed source: 'services-platform:modules/workflow-actions/services/persistence/business-calendars.ts:clearOtherDefault' - id: INV-DOM-PFM-INT-006-07 statement: 'A rule can have only one draft, and database protection prevents modifications to published versions.' enforced_at: - service - database provenance: test source: >- services-platform:modules/workflow-actions/tests/integration/db/workflow-actions-tables.integration.spec.js#refuses a change to a published version’s actions - id: INV-DOM-PFM-INT-006-08 statement: >- Publication needs an active automation event, permitted condition facts, a valid nonempty action list and all required publisher permissions. enforced_at: - service provenance: test source: >- services-platform:modules/workflow-actions/tests/integration/services/automation/publish-automation-rule.integration.spec.js#refuses a publisher without the permission an action’s type requires - id: INV-DOM-PFM-INT-006-09 statement: >- An event host reads at most two hundred enabled rules at their current published versions and raises their matching actions within its transaction. enforced_at: - service provenance: test source: >- macroservice-libraries:packages/workflow-actions/src/tests/integration/automation.integration.spec.ts#raises each matching rule’s actions as platform.automation_rule, rule and version, at event, once per event physical: - platform.trigger_points - platform.action_types - platform.action_templates - platform.shipped_action_templates - platform.workflow_templates - platform.shipped_workflow_templates - platform.business_calendars - platform.automation_rules - platform.automation_rule_versions - platform.cross_workflow_action_runs (view) - platform.cross_workflow_timers (view) evidence: - >- services-platform at ad3f6a65: modules/workflow-actions/db/*; services/registry/*; services/validation/action-lists.ts; services/automation/*; services/persistence/*; contracts/platform-declarations.ts; workflow-actions-objects.ts - >- services-platform at ad3f6a65: docs/workflow-actions/README.md, automation-rules.md, cross-service-views.md; docs/proposals/application-processes-and-workflow-actions/14-decisions.md (D-03, D-05, D-08, D-10) - >- macroservice-libraries at 54536a44: packages/workflow-actions (raise, automation, business-days, cross-views) --- # Workflow Action ## What It Models A workflow action is configured work raised at a host’s process moment or business event. The host executes it and owns its run. Platform supplies shared action and trigger declarations, copied recipes, business calendars, published automation rules and combined read-only run and timer lists. ## Identity and Attributes Trigger identity combines its host kind and key; action types have an application-owned key. Customer templates and calendars use configuration identifiers, while shipped templates reserve a system prefix. Rules have numbered versions with at most one draft. A trigger identifies the host moment, supplied facts, contract version and registry standing. Action declarations specify parameter and output schemas, executor, execution kind, permitted contexts, required authority and supported contract versions. Customer and shipped recipes contain an action or stage configuration that is copied into a destination definition. Calendars retain zone, working weekdays, optional hours, no more than four hundred holidays and a unique default flag within the workspace. A rule retains its event, derived owning application, description, status and current published-version reference. Versions retain conditions, actions, condition fingerprint, required permissions and publication attribution; published content is immutable. Shared read-only views combine hosts’ run and timer records, including attention information, without relocating those records. Replacements require the template, calendar or rule version previously read. ## Relationships An automation rule’s event should correspond to the application’s business-event declaration.. That relationship joins separate registries and remains unenforced.. An action executed by a host can invoke a provider capability through the gateway.. The host owns its action run and the integrations service owns the resulting capability execution.. ## Invariants Registry registration requires an active service principal for the application whose declarations it replaces. Ownership, host, execution-kind or contract-version conflicts reject the complete registration. The latest manifest retires entries it omits and restores entries it declares again. Template writes and automation publication validate actions against active types allowed for the chosen host and trigger. Using a template copies its settings into the destination definition, so subsequent template edits do not alter that definition. Only one calendar can be default in a workspace; selecting a new default clears the old flag in the same database transaction. A rule can have only one draft, and database protection prevents modifications to published versions. Publication needs an active automation event, permitted condition facts, a valid nonempty action list and all required publisher permissions. An event host reads at most two hundred enabled rules at their current published versions and raises their matching actions within its transaction. ## How It Is Stored and Shared The workflow-actions service owns its registries and customer configuration. Hosts read calendars and published rules in their own transactions and keep runs and timers in their schemas. Shared views include only hosts with complete published view contracts when rebuilt. Object registration enables no custom fields. ## Open Design Questions Connected screens and an adopted event-producing host remain unproven. The notification action is declared inactive. Deleting the default calendar can leave no default, and precomputed timer instants do not move after calendar edits.