Run a workflow

You can trigger a full workflow run by either clicking on the run icon from the Workflows hierarchy or by selecting Run All from the Actions menu within a specific workflow.

You can also click on the Toggle Start/Stop button at the top of the workflow table. This toggle button will stop a running workflow or start a workflow.

If you click Run on a workflow that’s already running, PlaidCloud tells you so instead of starting a second run.

Choose a Posting Mode

Every run carries an ERP posting mode. To choose one in PlaidCloud, use Run With Posting Mode in a workflow’s right-click menu, or the run-mode button on the workflow canvas; a plain Start Workflow or Run Workflow asks for Live, still subject to the project’s cap described below. You can also choose the mode when you start a run through the run API or the assistant.

Mode	What happens
Live	Posting steps post exactly as they always have. This is the default.
Simulate	Every ERP posting step builds and validates exactly what it would post, then commits nothing and never contacts the ERP. The would-post entries are recorded in ERP Post History, marked simulated, so you can review them before running live.
Off	Posting steps are skipped entirely.

A project also carries its own posting mode cap, set through the project API or the assistant by any member with write access to an unlocked project. The cap only ever makes a run safer, never more permissive: a run’s effective mode is the more restrictive of the mode you chose and the project’s cap, so a project capped to Simulate stays simulated even if you start the run as Live.

A scheduled event keeps its own posting mode, so a schedule set to Simulate runs simulated every time it fires.

The mode carries through everything the run touches. A sub-workflow, a macro, and a Run Model, Conditional Run Model, or Loop Model step all inherit the parent run’s mode, and so does a run you resume after a stop — a simulated run can’t post for real anywhere inside itself.

Authorize the Project to Post

A workflow run posts to an ERP as the project, not as the person who started it. Before a run can post, the project needs an authorization for each ERP connection and environment its posting steps use. Without one, the step fails with “This project isn’t authorized to post to connection …”, naming the connection and environment. The Call SAP Financial Document Attachment, Call SAP Master Data Table RFC and Call SAP RFC steps don’t need one.

To authorize a project, open its home page and select ERP Write Authorizations under ERP Posting. Each row is one connection in one environment. Tick Authorized to let the project post there, or clear it to stop. Authorized By and Authorized At show who last authorized it and when.

The button is shown to the project’s Architects and to workspace admins, but only an Architect can change an authorization, and only while the project is unlocked. A workspace admin who isn’t an Architect can add themselves as one first.
Selecting a row to authorize or clear it doesn’t reload the list: the scroll position and any column sort you chose stay where they are. The window can be resized, and the note about public projects wraps in full.
To authorize a connection, you also need write access to it yourself: you own it, or it is shared with you by name or through one of your security groups. A connection set to All Workspace Members doesn’t count.
A project set to All Workspace Members is authorized like any other. Every member is an Architect of it, so any member with write access to a connection can authorize the project for it. Once it’s authorized, any member can post to that connection from the project’s workflows, and the window says so above the grid.
A copied project, or one created from a project archive, starts with no authorizations. Authorize the copy before it posts.

Follow a Step’s Status

While a workflow runs, each step carries a status icon showing where it stands, alongside how long it has been running. Hover the icon for the message behind it.

Status	What it means
Waiting	The step is queued and hasn’t started yet.
Running	The step is working, and its duration counts up as it goes.
Completed	The step finished successfully.
Warning	The step finished, but flagged something worth reading in the workflow log.
Error	The step failed. See Managing Step Errors.
Skipped	The step was passed over — it’s disabled, or its run conditions weren’t met. See Skip Steps in a Workflow.
Continued	The step failed but is set to continue on error, so the workflow carried on. See Continue on Error.
Stopped	The run was stopped before the step could finish.
Abandoned	The step’s execution was interrupted, so it will never finish. Resume the run, or re-run the workflow.

An open workflow view refreshes on its own as a run progresses, so the statuses you’re looking at stay current without reloading the page.

Abandoned Steps

A step is marked abandoned when whatever was executing it went away mid-run — most often because someone pressed Stop, or because platform maintenance interrupted the run. The step’s duration stops climbing and the status tooltip explains what happened.

An abandoned step did not complete and produced no output. It is not a slow step, and it is not a problem with your data or your configuration.

To pick the work back up, either Resume the run — the abandoned step runs again — or re-run the whole workflow. Both are safe.

Interrupted Steps

If the server running a step is lost mid-run, PlaidCloud re-runs the step automatically when it is safe to repeat: a step that replaces its output ends up with the same result as a single clean run, so you have nothing to check.

A step that can’t be repeated safely isn’t re-run. It fails once with an interrupted message, because running it a second time could duplicate what the first attempt already wrote. Steps that write outputs with {date} in the name or path count as not safe to repeat, since a re-run could land on a different date. To recover, check the step’s target for what the first attempt wrote, clean it up if needed, then re-run the step or Resume the run.

Steps That Never Start

If no worker picks up an import or dimension step’s job within about 40 minutes, the step fails instead of showing Running until the 24-hour timeout. If a worker started the job and then went away, the step also fails, with a message saying the worker stopped. Both messages say “Use Run from here to retry.”

Pause, Stop, and Resume

While a workflow is running you can Pause it, so that in-flight steps finish and new steps wait, or Stop it, which cancels the steps that were queued and any import or export jobs that are still running. Import and dimension steps that were still queued are cancelled cleanly, so they don’t hold up later imports and dimension loads in the workspace.

Resume picks a paused, stopped, or failed run back up from where it left off instead of starting over. It is available whenever a workflow’s last run ended in a paused, stopped, or error state.

What “where it left off” means depends on how the workflow runs:

Execution	On resume
Serial	Restarts at the step that was running when the run ended, and continues from there. If that step is inside a group, Resume picks up the whole top-level group holding it: steps in the group that already finished successfully are left alone, the others run, and the run continues after the group.
Parallel	Re-runs every step that had not yet finished successfully, and leaves completed steps alone.
Advanced (graph)	Re-runs the node that failed and everything still waiting on it, and leaves completed nodes alone.

Steps that call another workflow — Run Model, Conditional Run Model, and Loop Model — resume the workflow they call rather than restarting it, through however many levels of nesting you have. A loop step resumes the iteration that was interrupted and skips the iterations that already completed.

When you Resume a workflow that ran as a nested child of another — one a Run Model step in a parent invoked — PlaidCloud offers Resume from top of chain. Resuming the child on its own cannot continue the parent’s orchestration, so this option resumes the top-level parent instead — the root of the chain — and continues the whole chain from where it stopped. Resuming a top-level workflow is unchanged. The top of the chain is resolved within the same project: a chain that crosses into another project resumes from the top of the in-project portion.

Resume always continues the original run. It re-runs every step from that run that did not finish successfully — a step that failed or was abandoned is re-run, not treated as complete — and re-running an individual step on its own in the meantime does not change what Resume picks up next.

A resumed run is recorded as a new run in the workflow’s run history, containing only the steps it re-ran. The original run keeps its own history entry.