# Runs And Step States
## Run Step Status
Steps on runs are like a checklist indicating what work was done and how. Each step in a run has a unique state. That state indicates the status of the work called out in the step's work instructions. Below are all of the states of a Run Step and the different states they can transition to.
Run Step States
### Available to Work
Available to Work is a separately calculated attribute that ION uses to help indicate to users whether or not a run step can be worked on. It's calculated by taking into account the following:
* Are all upstream dependent run steps **Completed**?
* If a parent step exists, then is it **In Progress**?
* Is the current step in **Todo** or **In Progress?**
* ***Future State:*** Are all blocking issues resolved?
If all of the conditions are met then the step is considered Available to Work.
## Run Status
{% hint style="info" %}
The run calculates its status based on the status of its steps. This gives teams a high level overview of the state of the run! Below are the states of a run.
{% endhint %}
### Todo
This is the initial status for steps when they are created. A step in **Todo** means no work has been done against that step.
A run with steps all in **Todo** will also show the state as **Todo**
### In Progress
A step **In Progress** has been started by a user. Steps can only be moved from **Todo** to **In Progress** if all their upstream dependencies have been moved to the **Complete** state. Transitioning a step from In Progress to any of the other states as seen below will automatically check out all users who are currently checked into that run step.
### Completed
A **Completed** step has had all its required fields filled out and all its work completed.
Runs with all steps **Completed** will also be **Complete**
### Hold
**Hold** is a special administrative state used to prevent steps from being executed. This could be used to block work from being done or to pause an operation while an issue is being investigated.
A run with at least one step in **Hold** status will also inherit the **Hold** status.
{% hint style="info" %}
Steps in **Hold** state are called out in yellow.
{% endhint %}
### Redline
**Redline** steps are in an editable state and cannot be executed. See the [**Redlines**](https://manual.firstresonance.io/features/runs/redlining) page for more information.
A run with at least one step in **Redline** status will also inherit the **Redline** status, and the Redline status takes precedence over the Hold status.
{% hint style="info" %}
Steps in **Redline** state are called out in light red.
{% endhint %}
### Failed
**Failed** steps indicate something went wrong. This could be a part or process was found to be non-conforming or an inspection was failed. You can trigger this step by clicking the **Fail Step** button in execution mode after this step has been started.
A run with at least one step in **Failed** status will also inherit the **Failed** status.
{% hint style="info" %}
**Failed** steps are colored dark red.
{% endhint %}
If set up in your organization settings, a Failed step will automatically trigger the creation of an issue ticket. From here, you can insert your cause, expected condition, and disposition.
You are able to freely change a runstep from Failed status to `Todo` or `Redline`.
### Canceled
If a user with appropriate privileges decides that a step can be skipped, they can cancel the step. Canceled steps can be moved back to **Todo** to be un-canceled.
If every step in a run is canceled, it will calculate its status as **Canceled.** If the run is comprised of a mix of **Complete** and **Canceled** steps, it will use the status **Partial Complete** to indicate no more work can be performed but not all the work was done. Otherwise, the run will use the other rules from the above states to calculate its status.
{% hint style="info" %}
**Canceled** steps are displayed in dark gray
{% endhint %}
#### Canceled Steps Dependency
{% hint style="info" %}
Contact your Customer Success Manager to opt out of non-blocking canceled steps.
{% endhint %}
Run steps can have dependencies on other run steps which prevent them from being worked on. Consider the dependency graph below, Step 4 `Assemble tail` has two dependencies - `Step m1` and `Step m2`. Only `Step m1` is blocking since `Step m2` is complete.
If we cancel a `Step m1`, we have decided it can be skipped and it should no longer block other steps, so it is removed from the dependency graph. The dependency graph is rewired to ensure its dependencies remain in tact. `Step h1` which was blocking `Step m1` is now blocking step `Assemble Tail` as seen below. `Assemble Tail` can now be worked since all of its dependencies have been completed. This feature prevents canceled steps from blocking downstream steps while the dependency graph makes sure work gets done in the correct order.
In batched runs, each run will receive this behavior when canceling a step. Each corresponding step will be removed from the dependency graph and each dependency graph will be rewired to ensure dependencies remain in tact.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://manual.firstresonance.io/features/runs/runs-and-step-states.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
