Workflows

Overview

Rescale Workflows lets your team build, share, and run reusable multi-step simulation pipelines on the Rescale platform. A Workflow Template is a connected graph of nodes — representing jobs, workstations, storage devices, decision logic, and agents — that you configure once and run repeatedly with different inputs. This eliminates manual handoffs between pipeline stages and preserves your team’s simulation best practices in a format any engineer can execute.

Benefits

  • Visual template builder — Compose multi-step simulation pipelines on a drag-and-drop canvas without scripting
  • Two-persona design — Template builders configure the workflow once; runners execute it by providing only the inputs required for each run
  • Conditional logic — Use Decision nodes to route execution based on outputs from upstream steps (for example, selecting hardware based on mesh size)
  • Managed data transfer — Shared storage connects nodes so that output files from one step are automatically available to the next
  • Reusable, shareable templates — Save templates and share them across your team so your best simulation processes become organizational assets
  • Node-level failure controls — Configure each node independently to continue or stop the workflow on failure. When a node fails, only its downstream dependents are blocked — independent branches keep running and compute everything they can.
  • Concurrency limits — Set the maximum number of nodes that can run at the same time to stay within software license limits or manage cluster resources.
  • Retry failed runs — When a workflow run partially fails, retry it without re-running nodes that already succeeded. Fix what went wrong in the template, and the platform re-executes only failed, changed, and downstream nodes.
image 278

Prerequisites

Before building or running a workflow:

  • You must have access to a Rescale account with Workflows enabled. Contact your Rescale representative to enable Workflows for your account.
  • To run a workflow, you must be the workflow template owner or ensure the workflow template is shared with you

Building a Workflow Template

A Workflow Template is the reusable foundation of every workflow run. You build a workflow template once — configuring nodes, connecting them in sequence, and defining the parameters that runners fill in at execution time. Once saved, it can be shared with your team and run as many times as needed without modification.

1. Navigate to Workflows

  1. Sign in to the Rescale platform.
  2. In the left navigation, click Workflows.
  3. Click New Workflow and + Create New Template to open the canvas for building a workflow template
image 274

2. Add Nodes to the Canvas

The canvas is a drag-and-drop workspace where you compose your pipeline from a palette of node types. To run a workflow template, you need at least one node. 

  1. In the node palette, drag a node type onto the canvas. Available node types are:
    • Job — Runs a simulation or compute task on Rescale hardware
    • Workstation — Launches an interactive workstation session for pre- or post-processing or other interactive tasks
    • Storage Device — Mounts a persistent shared storage volume accessible to all connected nodes
    • Decision — Evaluates a condition and routes execution to one of two downstream branches
    • Agent — Connects a pre-built AI agent (such as an Input Validator or Troubleshooter) into the pipeline
  2. Select the node on the canvas. Its configuration form opens in the bottom panel.
  3. Fill in the node configuration — software, hardware, commands, and other settings — the same way you would configure a standalone job or workstation on Rescale.
Screenshot 2026 04 27 125339

Tip: If your workflow passes files between steps, add a Storage Device node first and connect it to your downstream nodes. All connected nodes will share the same storage volume automatically.

3. Connect Nodes

Connections define execution order. A downstream node does not start until all nodes it depends on have completed.

  1. Hover over the edge of the node you want to run first. A connection handle appears.
  2. Click and drag from the handle to the next node in your pipeline.
  3. Release to create the connection. Repeat for each step in sequence.

To create parallel branches, connect one upstream node to multiple downstream nodes. All of those nodes start simultaneously when the upstream node completes.

Tip: To delete a previously defined connection, select the connection and use the Backspace key. 

4. Define Workflow Parameters

Workflow parameters let runners customize the workflow at execution time without modifying the template itself. Define them once; runners provide values when they submit a run.

  1. In the Parameters panel, click Add Parameter.
  2. Enter a name and choose a type:
    • String — A text value (for example, a solver flag, output directory name, or analysis label)
    • File — Prompts the runner to upload a file or select one from existing cloud storage
    • Storage Device — Prompts the runner to select a running shared storage device; Rescale automatically attaches it to all nodes in the workflow
  3. Set the parameter as Required or Optional.
  4. To use the parameter inside a node’s configuration, insert the following reference anywhere in that node’s fields — for example, in a job command or a file path:

${parameters[“<parameter name>”]}

The Workflow Builder will often populate this reference automatically or from a dropdown when you’re editing a node field.

image 275

5. Reference Upstream Node Outputs (Optional)

Dynamic value references let you pass outputs from one node directly into the configuration of a downstream node at runtime — for example, using a completed job’s resource ID as an input for the next step.

To reference the resource ID of an upstream node:

${nodes[“<node name>”].data.execution.resource_id}

Insert this reference in any node configuration field where you want to use the upstream value. It resolves automatically when the workflow runs.

6. Configure Workflow Settings

Workflow-level settings control execution behavior across all nodes. Open Workflow Settings by clicking the gear icon in the top-right corner of the template editor.

Concurrent Nodes

By default, all nodes whose dependencies are met run at the same time. To limit how many nodes can be active simultaneously — for example, to stay within software license limits — enable Concurrent Nodes and set the maximum with the numeric stepper.

When the limit is reached, additional ready nodes wait in a queue until a running node completes. Nodes execute in topological order (upstream before downstream).

  1. Click the gear icon to open Workflow Settings.
  2. Toggle Concurrent Nodes on.
  3. Set the number to the maximum nodes you want active at once.
  4. Click Save.
concurrent nodes

Continue on Failure (All Nodes)

To allow the workflow to keep running independent branches when any node fails, click Set For All Nodes next to Continue on Failure in Workflow Settings. A confirmation message appears: Continue on Failure set for all nodes.

This sets the failure tolerance on every node at once. You can then override individual nodes as described in the next section.

7. Configure Node Failure Behavior

By default, a node failure stops all downstream execution. You can override this per node so that only the failed node’s direct dependents are blocked while independent branches continue.

  1. Select a node on the canvas to open its configuration panel.
  2. Scroll to Node Properties at the bottom of the panel.
  3. Enable Continue workflow execution if this node fails.

When this setting is on and the node fails, only its downstream dependents stop. All other branches that do not depend on the failed node continue executing — the workflow computes everything it still can.

Note: Decision node failures always halt the workflow regardless of this setting, because the system cannot determine which branch to take without the decision result.

8. Save the Workflow Template

Click Save. Your template appears in the Workflows list and is ready to run or share.

9. Share the Template (Optional)

  1. Open the workflow template from the Workflows list.
  2. Click Share.
  3. Search for and select the recipients you want to add.

Recipients can view and submit the workflow, but cannot edit the template. Workflow runs they create are owned by them.

Running a Workflow

Running a workflow uses a saved template. You provide the required inputs; the platform handles execution, sequencing, and data transfer automatically.

1. Open a Workflow Template

  1. In the left navigation, click Workflows.
  2. Click New Workflow, find the template you want to run — your own, or one shared with you — and click Use Template.

Tip: To organize workflow runs into folders, click New Workflow from the folder in which you would like to create the workflow run, from the Workflows tab of Workspace Folders.

2. Submit the Workflow Run

  1. In the submission form, provide values for all required parameters:
    • For String parameters, enter the value in the text field.
    • For File parameters, upload a file or select one from your existing cloud storage.
    • For Storage Device parameters, select a running storage device from the dropdown.
  2. Review your inputs, then click Run Workflow.

Rescale creates a workflow run and begins executing nodes in the order defined by the template.

image 279

3. Monitor the Workflow Run

  1. In the left navigation, click Workflows, then select Workflow Runs. 
  2. Click the name of your run to open the run view.
  3. Alternatively, from the Workflows tab of Workspace Folders, click the name of your run to open the run view. 

The run view shows the same canvas as the template, updated with the live status of each node:

StatusMeaning
PendingWaiting for an upstream dependency to complete
RunningCurrently executing
CompletedFinished successfully
FailedEncountered an error
  1. To inspect a specific node, click it on the canvas. The Execution Details panel shows its current status and a direct link to the underlying resource — the job, workstation, or storage device — where you can view logs and outputs.

4. Retry a Failed Workflow Run

When a workflow run has failed nodes, you can retry it without re-running nodes that already succeeded. The platform identifies which nodes need to re-execute and reuses outputs from the original run for everything else.

  1. Open the workflow run that failed or partially failed.
  2. Click Retry in the upper-right corner of the run view.
  3. The workflow template editor opens with a color-coded overlay showing the status of each node from the original run:
ColorLabelMeaning
GreenCompleted, can be reusedSucceeded and unchanged — will be skipped
RedFailed, will retryFailed or never ran — will re-execute
OrangeChanged or downstream of a change, will re-runConfiguration was modified, or depends on a node that changed
GrayDid not run, will runBlocked by an upstream failure — will execute for the first time
  1. Fix the configuration that caused the failure directly in the template. For example, correct a command, change a software setting, or update an input file reference. Any configuration changes you make are saved to the template before retrying.
  2. Click Retry Workflow to launch the continuation run.
retry workflow

The retried run links back to the original run for traceability. Nodes that were skipped display their reused outputs from the original run.

Workflow Templates from Rescale

Rescale provides pre-built workflow templates for common CAE scenarios to help you get started quickly. When you click + New Workflow, you’ll see Rescale-provided templates that you can use as-is or duplicate and modify to fit your specific needs.

Available Templates

Rescale offers four workflow templates covering common simulation pipeline patterns:

  1. Pre- and Post-Processing Pipeline — Chain pre-processing, solver, and post-processing steps
  2. Dependent Job Configuration — Configure downstream jobs based on upstream results
  3. Admin Template / Job Configuration Management — Centralized template management for team-wide job configurations
  4. Agent-Enhanced Workflow — Include AI agents for automated validation and troubleshooting

Using a Rescale Template

  1. In the left navigation, click Workflows and click + New Workflow
  2. Alternately, from the Workflows tab of the Workspace Folder view, click + New Workflow
  3. Browse the available Rescale templates.
  4. Click Use Template to run the template as-is with your own parameter values
Rescale templates

Reviewing or Modifying a Rescale Template

  1. In the left navigation, click Workflows.
  2. Select a template to review the template configuration.
  3. Click Duplicate to create an editable copy you can customize.

When you duplicate a template, it becomes your own workflow template that you can edit, save, and share independently.

Pre- and Post-Processing Pipeline

workflows preprocessing pipeline

Overview

This template demonstrates a classic fan-out/fan-in pattern where a pre-processing job generates multiple input files, those files are processed in parallel by separate solver jobs, and a final post-processing job consolidates all results. File transfers between stages are handled automatically through Output Fields.

Use Case

Ideal for simulation workflows where:

  • A pre-processor generates multiple input files or model variants
  • Each input file needs to be processed independently (can run in parallel)
  • Results from all parallel runs need to be consolidated or compared
  • You want to maximize efficiency by running solvers in parallel rather than sequentially

Workflow Execution Flow

  1. Generate Models runs first and creates three model files
  2. Job1, Job2, and Job3 start simultaneously once Generate Models completes (parallel execution)
  3. Post Process waits until all three jobs complete, then consolidates their outputs

This parallel execution pattern significantly reduces total runtime compared to running the three jobs sequentially.

Parameters

This template is configured to run as-is without requiring runtime parameters. All input files and configurations are built into the template. However, you can duplicate this template and add parameters for your specific use case.

Dependent Job Configuration

workflows template dependent job config

Overview

This template demonstrates how to dynamically route execution to different job configurations based on outputs from an upstream step. A Decision node evaluates a Custom Field value set by the pre-processing job and routes to either a large or small hardware configuration depending on problem size.

Use Case

Ideal for workflows where:

  • Hardware requirements depend on problem characteristics (mesh size, file size, element count)
  • You want to automatically right-size resources rather than manually selecting hardware each time
  • Cost optimization is important — avoid overprovisioning small jobs or underprovisioning large ones
  • Pre-processing outputs metadata that determines solver requirements

Workflow Execution Flow

  1. Generate Mesh runs and creates the mesh file
  2. Generate Mesh adds a Custom Field (MeshSize) with a value representing problem size
  3. Decision node evaluates the MeshSize Custom Field value
  4. Either Large Job or Small Job runs (not both) based on the decision outcome

Key Concepts

Custom Fields for Dynamic Routing

This template uses Custom Fields to pass metadata from one job to a Decision node. The pre-processing script can store any numeric or string value to a Custom Field that represents problem characteristics.

The Decision node references this Custom Field using the syntax:

nodes[“<node name>”].data.outputs.customFields[“<field name>”]

Extending This Pattern

You can extend this template to:

  • Add more decision branches (e.g., Small/Medium/Large/XLarge hardware tiers)
  • Route based on multiple conditions (mesh size AND analysis type)
  • Select different solver versions or configurations based on problem type
  • Chain multiple decisions for complex routing logic
  • Modify the Custom Fields generated to represent mesh or compute element count, file sizes, or other complexity metrics

Parameters

This template is configured to run as-is without requiring runtime parameters. The routing decision happens automatically based on the MeshSize Custom Field. However, you can duplicate this template and add parameters for:

  • Input files — Upload a real mesh file instead of generating a dummy one
  • Solver version — Choose solver version per hardware tier

Admin Template / Job Configuration Management

workflows template admin management

Overview

This template demonstrates centralized configuration management for multiple solvers in a single workflow. Template builders (admins or simulation experts) pre-configure approved software versions and hardware for each solver, then share the template with end users who simply upload an input file. The workflow automatically routes to the appropriate solver based on file type.

Use Case

Ideal for organizations where:

  • Simulation experts need to enforce standardized solver versions and hardware configurations
  • Multiple users run different types of analyses (Abaqus, LS-DYNA, Python, etc.) with consistent settings
  • You want to simplify the user experience — runners don’t need to know which hardware or solver version to select
  • Configuration management and license compliance are critical
  • You want to control access to specific software versions or hardware types

Workflow Execution Flow

  1. Runner uploads an input file and software version through the workflow submission form
  2. First Decision (Abaqus INP) checks file extension:
    • If .inp → runs Abaqus Job, workflow completes
    • If not → continues to next decision
  3. Second Decision (LS-DYNA DYN) checks file extension:
    • If .dyn → runs LS-DYNA Job, workflow completes
    • If not → continues to next decision
  4. Third Decision (Python PY) checks file extension:
    • If .py → runs Python Job, workflow completes
    • If not → workflow completes with no job execution

Only one job runs per workflow execution. Decision nodes evaluate in sequence until a match is found.

Key Concepts

Centralized Configuration Management

Template builders (admins/experts) control:

  • Which solver versions are available to users
  • What hardware configurations are used for each solver
  • Which file types are supported
  • Any additional job settings (environment variables, license servers, etc.)

Runners (end users) only need to:

  • Upload their input file
  • Optionally select from admin-approved solver versions
  • Click Run

Restricting User Access

This pattern is especially useful for:

  • License compliance — limit which users can access expensive licensed software
  • Cost control — restrict large hardware to specific use cases
  • Best practices — ensure users run with validated solver versions and settings
  • Onboarding — simplify the platform for new users who don’t know optimal configurations

Extending This Pattern

You can adapt this template to:

  • Add more solvers (OpenFOAM, ANSYS,STAR-CCM+, etc.)
  • Route based on more complex conditions (file size, file content, user group)
  • Include different hardware tiers per solver (Small/Medium/Large configs)
  • Branch to different job configurations for the same solver (explicit vs implicit, 2D vs 3D)
  • Combine with pre-processing or post-processing nodes

Parameters

Input File (File parameter)

  • Type: File
  • Required: Yes
  • Purpose: The runner uploads their solver input file (.inp, .dyn, .py)
  • Note: The workflow uses the file extension to route to the appropriate solver

Solver Version (String parameter with restricted options) — Optional

  • Type: String with dropdown
  • Required: Yes
  • Purpose: Allows runners to select from admin-approved solver versions
  • Configuration: Template builder defines the allowed options
  • Note: This parameter can be omitted if the template builder wants to lock the solver version entirely

Admin Configuration Checklist

When duplicating this template for your organization:

  1. Configure each Job node:
    • Select approved solver version
    • Select hardware (core type, core count, memory)
    • Add any required environment variables or license server settings
    • Set job timeouts and other limits
  2. Set up parameters:
    • Create File parameter for input file upload
    • Optionally create String parameters with restricted options for solver version selection
    • Optionally add Project parameter for cost tracking
  3. Share the template:
    • Share with team members as Viewers (they can run but not edit)
    • Keep Editor access restricted to admins/experts who manage configurations

Agent-Enhanced Workflow

workflows template agent enhanced

Overview

This template demonstrates how to integrate AI agents into your simulation workflows for automated input validation and failure troubleshooting. The workflow validates input files before running expensive compute jobs and automatically diagnoses failures when they occur, saving time and reducing manual debugging.

Use Case

Ideal for workflows where:

  • Input validation before expensive solver runs can save time and cost by catching issues early
  • Automated troubleshooting can diagnose common failure modes without manual intervention
  • You want to prevent jobs from running with invalid or incomplete inputs
  • Simulation experts want to capture domain knowledge in automated pre-flight checks
  • Reducing time-to-resolution for job failures is a priority

Workflow Execution Flow

Happy Path (Validation Passes, Job Succeeds):

  1. ValidateInputFile checks the input file
  2. Validation passes → Validated Decision routes to True branch
  3. Python Job runs successfully
  4. Job Complete Decision routes to True branch
  5. Workflow completes ✓

Validation Failure Path:

  1. ValidateInputFile checks the input file
  2. Validation fails → Validated Decision routes to False branch
  3. Workflow stops (no job runs, no compute cost incurred)
  4. User reviews validation feedback and fixes input file

Job Failure Path (Validation Passes, Job Fails):

  1. ValidateInputFile checks the input file
  2. Validation passes → Validated Decision routes to True branch
  3. Python Job runs but fails (runtime error, timeout, etc.)
  4. Job Complete Decision routes to False branch
  5. TroubleshootJob analyzes the failure and proposes fixes
  6. User reviews troubleshooting report and resubmits with corrected input

Key Concepts

Why Use Agents in Workflows?

Agents bring automated intelligence to pipeline stages that traditionally require manual intervention:

  • Pre-flight validation prevents wasted compute by catching bad inputs before jobs run
  • Automated diagnostics reduce time spent manually analyzing logs and error messages
  • Consistency applies the same validation rules and troubleshooting logic to every run
  • Knowledge capture embeds expert knowledge (what to check, how to diagnose) into the pipeline itself

Available Agent Types

Rescale provides two agent types for workflows:

  1. Input Validator — Checks input files before jobs run
    • Validates file format and syntax
    • Checks for required fields or parameters
    • Verifies compatibility with solver versions
    • Flags common errors or warnings
  2. Troubleshooter — Analyzes failed jobs and proposes fixes
    • Examines job logs and error messages
    • Identifies root cause (syntax, dependencies, resources, etc.)
    • Suggests corrective actions
    • Can propose corrected input files

When to Use Each Agent

  • Input Validator → Use before any expensive job where input errors are common
  • Troubleshooter → Use after jobs prone to failure where manual debugging is time-consuming

Extending This Pattern

You can adapt this template to:

  • Add validation and troubleshooting to multi-step workflows (validate before each solver stage)
  • Use agents with real solvers (Abaqus, LS-DYNA, OpenFOAM, etc.) instead of Python
  • Combine with other patterns (validate inputs before a Pre/Post-Processing Pipeline)
  • Add custom validation rules specific to your domain

Parameters

InputFile (File parameter)

  • Type: File
  • Required: Yes
  • Purpose: The Python script (or solver input file) to validate and run
  • Usage:
    • Passed to ValidateInputFile agent for validation
    • Passed to Python Job for execution (if validation passes)
    • Included in TroubleshootJob analysis (if job fails)

Benefits of This Template

Cost Savings

  • Catch invalid inputs before allocating compute resources
  • Avoid wasted job runs that fail immediately due to input errors

Time Savings

  • Automated validation is instant vs. waiting for a job to fail
  • Automated troubleshooting is faster than manual log analysis

Consistency

  • Same validation checks applied to every run
  • Same troubleshooting logic applied to every failure

Onboarding

  • New users get immediate feedback on input file issues
  • Troubleshooting agent teaches users what went wrong and how to fix it

Customizing Templates

After duplicating a Rescale template, you can customize it like any workflow template:

  • Add or remove nodes
  • Modify node configurations
  • Add or change parameters
  • Adjust connections and execution order
  • Save and share your customized version

FAQs

Can I run jobs in parallel within a workflow?
Yes. Connect one upstream node to multiple downstream nodes to run them in parallel. All parallel branches start when the upstream node completes, and any node downstream of all of them waits until every branch has finished.

What happens if a node fails during a workflow run?
By default, if a node fails, its dependent downstream nodes will not start. If your workflow has “continue on node failure” enabled, execution continues — and any Decision node that depends on the failed node will route to the false branch.

What is the difference between a Workflow Template and a Workflow Run?
A Workflow Template is the saved configuration — the node structure, connections, and parameters. A Workflow Run is an active instance created when someone submits the template with specific parameter values. Each run is independent and does not modify the underlying template.

Can I edit a workflow template after sharing it?
Yes. You can edit your own template at any time. If you share a template with someone else, they can run and view it, but they cannot edit it. Changes to the template do not affect runs that are already in progress.

Can I reuse files or storage across multiple workflow runs?
Yes. If you use a Storage Device parameter, runners can select the same shared storage device across multiple runs — allowing them to build on results from previous runs or share data across campaigns.

Who can see my workflow runs?
Each workflow run is owned by the user who submitted it. If you share a template with a teammate and they submit a run, that run belongs to them and does not appear in your Workflow Runs list.

×