---
id: CON-PFM-INT-006
name: Workflow Action
feature: FEAT-PFM-INT-06
product_area: platform
module: integrations
revision: 1
status: draft
product_intent: proposed
implementation_evidence: observed
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
  macroservice-libraries: 54536a441935c6e09fdb7f96f0bec71c52ba4e03
definition: >-
  A workflow action is configured work raised at a process moment or business event and executed by its owning
  application using shared declarations.
owned_by: MOD-PFM-INT
synonyms:
  - Action
  - Automation
not_to_be_confused_with:
  - Application customization contract
  - Provider operation requested through the gateway
facets:
  - name: Trigger point
    meaning: A host declares the process moment or event and facts that can raise work.
    used_for: Offering valid places to configure actions.
  - name: Action type
    meaning: >-
      A declared action has settings and output contracts, execution kind, permitted contexts and required
      authority.
    used_for: Providing useful and valid choices to an action builder.
  - name: Action template and workflow template
    meaning: >-
      Shipped or workspace recipes contain reusable action settings or workflow stages that are copied when
      adopted.
    used_for: Preparing definitions without coupling them to later recipe edits.
  - name: Business calendar
    meaning: 'A calendar describes local working days, optional hours and holidays with at most one workspace default.'
    used_for: Interpreting durations expressed in business time.
  - name: Automation rule
    meaning: 'An event rule combines a condition, actions, lifecycle and versioned publication.'
    used_for: Selecting work to raise when its owning application observes the event.
  - name: Run and timer
    meaning: The host retains action executions and scheduled future work in its own records.
    used_for: Investigating results and upcoming timers across applications.
relationships:
  - to: CON-PFM-INT-005
    statement: >-
      Automation uses business-event triggers declared for its host and must align with the event producer’s
      meaning.
    provenance: inferred
    source: 'services-platform:docs/workflow-actions/automation-rules.md#Automation rules: the engine''s third host'
    note: >-
      The design expects compatible event or action meaning across these mechanisms; automation validates its
      trigger registry rather than joins extension event types, and the complete host path is not established
      by these sources.
  - to: CON-PFM-INT-003
    statement: A registered action may invoke a provider capability through the gateway.
    provenance: inferred
    source: >-
      services-platform:docs/proposals/application-processes-and-workflow-actions/14-decisions.md#D-03. One
      Workflow Action Engine, as a shared library plus a Platform module, serving stage runs, process-run
      steps and business events
    note: >-
      The design expects compatible event or action meaning across these mechanisms; automation validates its
      trigger registry rather than joins extension event types, and the complete host path is not established
      by these sources.
lifecycle:
  - state: draft rule
    meaning: The configuration is editable and supplies no event work.
    how_it_changes: Publication creates an enabled current version.
  - state: enabled
    meaning: Its current publication is eligible when the host raises the event.
    how_it_changes: Disable or retirement stops new use; edits prepare another draft.
  - state: disabled
    meaning: The publication remains stored without new use.
    how_it_changes: Enable restores use or retirement ends it.
  - state: retired
    meaning: The rule remains for historical references.
    how_it_changes: Its lifecycle cannot return to active use.
acted_on_by:
  - CAP-PFM-INT-018
  - CAP-PFM-INT-020
  - CAP-PFM-INT-021
  - CAP-PFM-INT-022
visible_to:
  - ACT-PFM-022
  - ACT-PFM-020
  - ACT-PFM-006
evidence:
  - >-
    services-platform source inventory: modules/workflow-actions/** (db tables and views, services/registry,
    services/validation, services/automation, services/persistence, contracts); docs/workflow-actions/*.md;
    docs/proposals/application-processes-and-workflow-actions/14-decisions.md.
  - >-
    macroservice-libraries source inventory: packages/workflow-actions (raise, automation, business-days,
    cross-views).
supersedes: []
---
# Workflow Action

## What It Is

A workflow action is configured work raised because a process reaches a declared moment or an application observes a business event. It may send a communication, create follow-up work or request a provider operation. The action type supplies a settings contract and execution meaning; the host determines when the configured action is raised and keeps the resulting run.

Platform provides shared declarations, reusable recipes, working calendars and published automation configuration. The owning application executes the work in its own context rather than transfers ownership of every action run to Platform. That distinction helps a product manager follow responsibility: common configuration can offer one vocabulary while a failed effect still belongs to the host whose business process raised it. Shared lists provide a cross-application view without becoming the execution owner.

## What It Is Not

An action is different from a condition deciding whether a transition may happen. It describes resulting work rather than a general permission to update arbitrary records. A provider capability call is the gateway record of one external operation. An extension supplies customized participation at an application point. Those records may relate to an action, but they explain different parts of the business behaviour.

## How It Is Used

Administrators use available action types and reusable recipes to prepare configuration for a host. An automation author drafts a condition and action list for a registered event, then publishes a stable version. Later edits prepare another draft rather than alter work already attributed to the publication. Operators inspect shared runs and timers to find failed effects or blocked scheduled work.

The practical boundary is the event-producing host. Configuration can be saved and published without proving that a real application raises the event. Library tests demonstrate the shared engine, while production adoption requires evidence from the owning application. No connected console currently supplies the full template, calendar, automation and operational experience within the examined scope.

## Its Facets

**Trigger and action type.** The trigger supplies context and facts; the action declaration supplies valid settings, outputs, permitted hosts and required authority. The builder combines them into appropriate choices.

**Recipes.** Shipped and customer action or workflow templates are reusable configuration. Adoption copies their contents so a later recipe edit does not rewrite an existing definition.

**Working calendar.** Local weekdays, hours and holidays make a business duration meaningful. The initial workspace default is configurable and can be deleted; it is not a permanent guarantee of a default.

**Automation publication.** Draft, enabled, disabled and retired standing governs new event work. Runs retain the published version responsible for them.

**Run and timer.** The host holds execution and future-work records. Shared views expose ordering and attention without relocating those records to Platform.

## How It Relates

Automation event meaning should agree with the application event producer and its business-event declaration. The shared engine can raise an integration action, which uses gateway capability calls and retains its own provider result. Extension configuration remains a separate mechanism for customized decisions rather than a substitute action host.

## What It Could Become

The product should prove a real event-producing application and decide where configuration and operational review belong in the console. The declared notification-centre action stays inactive until that dependency exists. Separate chapter calendars may be useful later, but current configuration should first make default selection and missing-calendar behaviour understandable. Design should also distinguish action recipes from working-time setup so each outcome has its own capability and acceptance obligations.