Shared action rules

Manual / Actions

Use these rules with the reference page for the action you are configuring.

Disable an action

Disable an action while developing a workflow. Use its power button or choose Disable action from Step actions. Its settings, connections, and position stay in place. Choose Enable action to restore its work. This applies to regular actions, including Start Workflow and Script. Triggers, controls, and terminals do not have this option.

When a job or Workflow Test reaches a disabled action, it passes the input unchanged through Success and shows Skipped: disabled. It publishes no outputs or variables. It resolves no credentials, expands no settings, and schedules no retries. Its incomplete settings do not block a run, but the graph must remain valid. Fix enabled steps that use its outputs before running. Test uses your draft state. Production uses the saved state. Changing the state does not change a job already running.

Outputs and error routing

Outputs. Each action publishes named values as ${steps.<step-slug>.<key>} for later steps. The slug is shown in the node bench (chapter 4.4).

Success and Error. An action that completes takes its Success port; one that fails takes its Error port if the error policy is Use error output, otherwise it goes to the workflow's Error handling (chapter 9). A failure of a kind Relay cannot classify stops the job rather than routing it. On any error path, ${error.message}, ${error.action_name}, ${error.action_id}, ${error.action_type}, ${error.failed_at}, and ${error.kind} are available; HTTP Request and Run shell command add more.

Automatic recovery

Native Iconik actions, CatDV actions, and HTTP Request can recover eligible temporary HTTP, server, rate-limit, and connection failures. The default gives the action five retry sends shared by all of its requests. Each logical request can be sent at most six times, including its original send, inside the action's two-minute Retry window. Increasing, varied delays and any valid Retry-After instruction consume that window. Admission queue time does not. Relay retries HTTP status 408, 429, 500, 502, 503, and 504 for a repeatable request. It can also retry temporary connection failures and a response that ends before Relay receives it completely. It does not retry authentication, permission, invalid-request, validation, response-decoding, cancellation, permanent Domain Name System (DNS), certificate, or unclassified failures. The action enters its error route only after recovery ends or when the failure is not safe to repeat. Job details show each attempt and distinguish Retry wait from active processing (chapter 11.4).

Reads can be repeated. A write is repeated only when Relay knows it was not applied or the action has a supported duplicate-prevention contract. If a sent write might have been applied, Relay reports the unknown outcome and does not send it again. For a native Iconik write, a 429 response is a documented rejection and can be retried. A sent 408 or 5xx Iconik write is not retried because its result may be unknown. HTTP calls made inside Script do not use this automatic recovery. A CatDV update is sent again only when CatDV itself refused it with a temporary status or the request provably never left Relay; anything else leaves the outcome unknown (How a CatDV step fails). A CatDV sign-in refused for want of a license seat is tried again inside the window, because the refusal proves no seat was taken.

Existing saved native Iconik and HTTP Request actions gain this bounded recovery behavior after upgrade. No workflow edit is required.

File handling

See File sources and destinations for the carried file, overwrite rules, symbolic links, and shared storage.