> For the complete documentation index, see [llms.txt](https://docs.sprinto.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sprinto.com/data-library/workflow-checks/how-workflow-checks-work.md).

# How Workflow Checks Work

Workflow Checks in Sprinto operate in two main stages: **Configuration** and **Resolution**. This process ensures that compliance activities are scheduled, evidence is collected, and results are tracked against audit requirements.

### Stage 1: Configuring Workflow Checks

You can configure Workflow Checks in several ways:

* **Dedicated Workflow Checks tab** – navigate to **Data Library → Workflow Checks** to create and manage checks.
* **Preconfigured checks** – some checks are automatically enabled when you activate compliance frameworks in Sprinto.
* **Manual configuration** – create new checks by selecting from templates, adding single checks, or bulk uploading via CSV.

When configuring a Workflow Check, you can define:

* **Title and description** – identify the purpose and scope of the check.
* **Instructions** – specify how evidence should be gathered or presented.
* **Frequency and triggers** – define how often the check runs (e.g., monthly, quarterly, annually).
* **Assignment** – designate an owner responsible for completing the check and, if required, add a reviewer for evidence validation.
* **Custom fields and zones** – capture organisation-specific details and map checks to relevant zones.

### Stage 2: Resolving Workflow Checks

Once configured, Workflow Checks activate according to their schedule. They are displayed with statuses such as:

* **Due** – the check is awaiting completion.
* **Critical** – the check is nearing its deadline.
* **Failing** – the check has not been completed within the defined timeframe.

Users can resolve active checks by:

* **Running the check** – upload evidence manually or through built-in templates to show that the compliance activity was completed. Evidence can also be provided as file uploads or links.
* **Marking as a special case** – when a check is not applicable, it can be marked as a special case. This records the check as “Passing” for the cycle but flags it under special case records for auditors.
* **Submitting for review** – if a reviewer is assigned, they validate the evidence and either approve, reject, or mark the check as a special case.

### Example Workflow

1. **Configuration** – An administrator sets up a quarterly **Disaster Recovery** check, assigning it to the IT team and enabling reviewer validation.
2. **Activation** – On the scheduled date, the check status changes to *Due*.
3. **Evidence submission** – The IT team uploads tabletop exercise notes using the built-in template.
4. **Review** – The reviewer validates the submission and approves it.
5. **Completion** – The check status is updated to *Passing* and recorded for audits.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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://docs.sprinto.com/data-library/workflow-checks/how-workflow-checks-work.md?ask=<question>
```

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.