Run history
Every execution of a Flow is called a run. The History tab in a Flow shows past ones.
The list
Heading: Previous executions.
| Column | Meaning |
|---|---|
| Start time | When the execution began |
| Since start | Elapsed time, relative |
| Duration | How long it ran |
| Steps | Number of steps executed |
| Status | Result |
Via Open you see a run in detail, via Refresh you reload the list.
Times appear relative: Just now, {n} minutes ago, {n} hours ago, {n} days ago. If no timestamp is known: Date unknown.
Status
| Status | Meaning |
|---|---|
| Done / Completed | Ran through fully |
| Error / Failed | Aborted |
| In progress | Currently running |
| Waiting | Waiting on an event |
| Created | Set up, not yet started |
| Test run | A test run, not a real execution |
"Waiting" usually isn't a problem
This status occurs by design when a Flow is waiting for something — a page that no one has submitted yet, or the end of a Wait step.
If waiting runs pile up, though, check whether the associated links actually reached the right people.
Viewing a run
When you open one, the editor shows the data of that run instead of the empty blueprint:
Displaying previous executions
This is data from a previous Flow execution. It was loaded automatically to illustrate the Flow's behavior.
Displayed are Executed at, Loaded at, Status, and Steps.
| Action | Effect |
|---|---|
| Select other | Switches to a different run |
| Remove | Leaves the data view |
The selection dialog is called Select execution; without data it shows No executions found.
The editor shows real values
In history mode, you see at every step what actually ran — not the configuration. This is the fastest way to understand why a Flow behaved the way it did.
Tracing errors
On every step:
| Action | Shows |
|---|---|
| Show details | Input and output data of the step |
| Show error details | The error message |
A tried-and-tested approach:
- Where does it break off? The Steps column shows how far the Flow got.
- What came in? Check the output at the last successful step.
- What was expected? Often a format doesn't match.
- Correct and repeat via Restart — same input, changed configuration.
What end users see
If a Flow fails while someone is filling in a page, this appears there:
This process step could not be loaded
The current step could not be executed due to a faulty configuration or an invalid value.
Please contact the person responsible for this process or your organization's administrator.
This message is your cue
If someone reports this text, go into the history of the affected Flow. The failed run is at the very top — along with the step where it failed.
Error notifications
If a run fails, ApptiveGrid sends an email. The subject names the Flow; the body contains the Flow name, Space name, and the error message of the step where it broke.
Recipients are everyone with the Manage role in the Space, plus the Flow's owner.
There are two versions of the email — the text tells you which case applies:
| The text says … | Meaning |
|---|---|
| An error occurred, check the details | A single failure; the Flow keeps running |
| The Flow was stopped and needs your attention | The Flow is switched off and won't run again until switched back on |
Three identical errors switch the Flow off
If the last three runs fail with the identical error message, ApptiveGrid switches the Flow off — the switch flips to off. After that, no event triggers a run until you switch it back on by hand.
This particular email is your cue: fix the cause before switching it back on — otherwise, after three more events, the same three failures pile up and the Flow switches off again.
A successful run, or a failure with a different message in between, resets the count. A Flow that fails every other time keeps running — and keeps sending emails.
Who doesn't get the email
People with Edit or View don't receive error notifications, even if they helped build the Flow. Whoever is responsible for a live Flow needs the Manage role — otherwise they also won't be able to switch it back on afterward.
An exceeded quota — such as the number of Flow steps included in the plan — switches the Flow off immediately, without waiting for three attempts.
Check in regularly
Even so, check the history of live Flows regularly — especially in the first few days after a change. Not every unwanted run is an error: a Flow that runs too often, or with wrong values, is technically successful and doesn't trigger an email.
Too many runs is also a finding
If the list grows faster than expected, the trigger usually isn't right:
- Entry was changed without a field condition starts on every little thing
- An action that writes to the triggering Grid starts the Flow again
- A CSV import triggers once per row