Skip to main content

Configure Flow steps

Flow steps are the ordered units of work performed after a Flow opens its configured data. This reference covers the step types available from the current Add Action... menu.

Scope

Use this page to select a step type and identify its required configuration. Detailed Map, Report, Transport, routing, command-line, SQL, scripting and linked-Flow behaviour belongs to the related specialist pages.

Supported step types

Add Action... optionPurposeRequired configuration and constraints
MapTransform source data into destination dataSelect a Map, then compatible Source Data and Destination Data items. The selected Map determines the required DB/File types.
ReportGenerate report output from source dataSelect a Report and compatible Source Data, then configure the output destination, type and details. Test file, printer and email effects separately.
Custom ScriptRun a Flow-scoped Velox scriptSelect the applicable source type/item and edit the script. Compile and test it with controlled data; use the Code Library as the scripting-reference authority.
Outbound TransportSend a file using a configured outbound TransportSelect an outbound Transport and File Definition source. Sending can create an external side effect even during manual execution.
File RouterCopy a processed source file to a route's File ConnectionSelect a File Definition source and configure routing events. Test mode suppresses the router's copy operation, but this does not make every other step side-effect-free.
Command LineStart a local command or processConfigure the command, execution method, credentials only if required, wait behaviour and delay. Restrict executable paths and arguments; see the Command Line step.
Custom SQLExecute SQL against database-backed Flow dataSelect DB Source Data and enter the reviewed SQL command. Empty SQL or a missing DB Definition cancels the step. Test write SQL only with an approved rollback method.
Sub ActionExecute another configured FlowSelect the target Flow. The called Flow inherits the parent test flag and local values, and contributes to the parent status and log context. Prohibit direct and indirect cycles; see the Sub Action step.

Options visible in inactive, backup or legacy source are not supported merely because an internal action type exists. This page does not document Call Plugin, Transaction Commit, DB Disconnect, Wait for File or Inbound Transport as current Add Action... options.

Common step settings

SettingAccepted valueEffect and constraints
Action StepUnique descriptive textIdentifies the step in the ordered list and execution log.
ActiveEnabled or disabledDisabled steps remain configured but are skipped. Do not use this as the only record of why a step is disabled.
Source DataCompatible Flow data itemSupplies the input required by the selected module or step type.
Destination DataCompatible Flow data item where applicableReceives output from a Map or other destination-capable step.
Ignore empty source data and continue processingEnabled or disabled where shownAllows applicable steps to continue when the source is empty. Enable only when empty input is a valid business outcome.
Delay (secs)Non-negative delay used by applicable stepsDelays execution of the step. Avoid using delay as a substitute for a reliable external-system readiness check.

Configure and order steps

  1. Add the required Flow data first.
  2. On Action Steps, select Add Action... and choose the required type.
  3. Enter a descriptive step name and select its module, source and destination.
  4. Complete the type-specific settings and clear Active until the step is ready for a controlled test. New action steps are active by default.
  5. Drag steps into the required execution order. A Flow executes active steps in list order.
  6. Save, reopen and verify the order and references.
  7. Test one new side effect at a time, then inspect the execution log and affected destination.

Example

An illustrative transformation Flow could use this sequence:

  1. Map validated orders — Map from a file-backed source item to a database-backed destination item.
  2. Create processing report — Report from the destination item to a controlled test file.
  3. Send accepted file — Outbound Transport from a generated File Definition after the transport is separately tested.

The example describes ordering only. Actual modules, fields, destinations and transport behaviour must come from the approved integration design.

Constraints and failure behaviour

  • A missing module, source or destination can cancel the affected step or stop the Flow depending on the step and execution policy.
  • Later steps should not assume output exists when an earlier step permits empty data or finishes with a non-success status.
  • Test Run is not a general rollback mechanism. Database SQL, Maps, Reports, scripts, commands and external calls may still cause effects unless their specific implementation prevents them.
  • Reordering a shared production Flow changes its business sequence. Preserve the prior order and have an explicit recovery plan.
  • A failed Sub Action contributes failure to the parent Flow. Velox has no confirmed cycle guard, so reject direct and indirect Sub Action cycles during design review.

:::warning Host and external-system access Command Line, SQL, script and Transport steps can execute with service-account permissions and affect systems outside Velox. Apply least privilege, sanitise logs and test against controlled endpoints. :::