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.