Skip to main content

From confirmed actions to workflows

When you have tested a sequence of connected-system actions, Make a workflow prepares reusable Automation configuration from that confirmed history. It creates a draft; historical action results are not rerun or copied as future inputs.

This is different from Test-to-Production configuration promotion, which is described in Publishing and governance.

Prepare the workflow​

  1. Open the connection's confirmed action history in Operations Studio.
  2. Choose Make a workflow and give it a name that describes the result.
  3. Select a manual/platform trigger or the intended inbound connection/event.
  4. Choose the confirmed actions to include and their order.
  5. Set explicit fixed inputs or mappings from the future event and earlier action results.
  6. Create the draft, then open it in Automations for review.

Only readable, confirmed actions with currently usable published contracts can supply the draft. Changed, suppressed or unavailable examples need review before proceeding. Historical inputs/results are deliberately not treated as the correct input for every future event.

Review the future data flow​

Select the trigger and check its source connection and event kind. For each action, check required fields, types and destinations. A later action may use a declared result from an earlier action only when that action runs on every preceding path.

Cycles, forward references, unknown result fields and incompatible types are rejected. For conditional branches, make sure every required source result is produced on every path to its consumer. Inspect both matching and nonmatching events in preview.

The new Automation is inactive until you publish and activate it. Creation alone does not execute any action, establish secure access or grant a service new authority. Konnie can prepare the same draft using your reviewed trigger and mappings; publication and execution use the same controls.

Operate a manual workflow in an App​

Bind an Action Button to the active manual Automation. In a Blueprint, the embedded button's immutable runtime configuration must contain that binding. Publish the App with the required workflow execution/read capabilities, and ensure its users also have the corresponding current permissions.

The button shows returned status, recent runs and refresh/resume controls. Manual invocation carries the configured App/component and permitted order/work-center references. Named App Automation actions can also pass bounded typed inputs as payload.appInput; configure the connection and mappings explicitly. See Automations in Apps.

Recover an interrupted run​

Refresh the existing run after a lost response. An offered Resume uses that persisted event and workflow version and does not create another trigger event. A changed publication, revoked access or processing restriction can block recovery and requires author/operator review.

Pending approval and an uncertain external outcome are separate from completion. Check the connected execution and receiving system before creating another deliberate invocation. Keep the run identifier when reporting a problem so the team can trace the existing attempt.

See Automations for graph authoring and Integrations for connection setup.