This article explains what project Status and Workflow States are, how the two interact, and how to configure them for your templates.

What is a Status and a Workflow State?

All projects in SiteCapture have a group of statuses that can be set as a project is worked on. Statuses are essential for keeping projects organized based on their completion.

Each Status has an attached Workflow State. The Workflow State determines what is affected by a change to the associated Status.

How to Configure Status and Workflow States

Status and Workflow States are configured from the template settings in the template editor. See: How to Create and Manage Templates to learn more.

In the template settings, you can manage Status and Workflow States under Manage Status Options.

Edit an Existing Status

Next to the Status option you wish to edit, click the blue edit icon.

You will now see the Edit Status Option menu.

Option Name
The name of the status that will display for users filling out projects.
Option Value
A separate value for each status that can be used for integrations.
Workflow State
Determines the behavior of the status and how it affects the project. See: Workflow States for more information.
Customer can't set this status
If checked, users with the Customer role will not be able to set projects to that status, even if they have been granted Admin permissions.
Field User can't set this status
If checked, users with the Field User role will not be able to set projects to that status, even if they have been granted Admin permissions.

Add a New Status

At the bottom of the Manage Status Options section, you can enter a Name and Value to create a new Status.

After creating the new status, edit it to add a Workflow State and manage user permissions. See: Edit an Existing Status

Workflow States

Each project status has an attached workflow state. The workflow state determines how a status change will affect a project.

Workflow State Reference
The table below outlines the behaviors associated with each workflow state. For each state, it shows whether it:

Enforces required fields for field users and vendor roles
Is set to Read-Only
Triggers notifications when marked Complete
Triggers notifications when marked Cancel
Is automatically set when the user clicks Yes on the completion prompt
Hides the project from the mobile user view when the Hide completed projects admin setting is:
- Enabled (checked)
- Disabled (unchecked)
Is hides the project from the web app view

Use this table as a quick reference to understand how each workflow state behaves across different system settings and actions.

Any user with a role that permits them access to all projects can always edit a project, even if it has been marked read-only.

Changing Statuses in the Web App

Managers and Portal Admins have the ability to change the status to "Complete" or any other status, regardless if the required fields are filled in. Click on the status drop down and select the status.

FAQ

What's the difference between a Status and a Workflow State?

A Status is the label users see and select on a project (like "In Progress" or "Complete"). Its attached Workflow State controls what actually happens in the system when that status is set, such as enforcing required fields, triggering notifications, or hiding the project from mobile view.

Where do I set up Status and Workflow State options?

In the template editor, under Manage Status Options in the template settings.

Can I stop certain roles from setting a status?

Yes. When editing a status, checking "Customer can't set this status" or "Field User can't set this status" removes that status as an option for those roles, even if they've otherwise been granted Admin permissions.

Can a Manager or Portal Admin mark a project Complete if required fields are empty?

Yes. Managers and Portal Admins can change a project to Complete or any other status regardless of whether required fields have been filled in.

Can a read-only project ever be edited?

Yes. A user with a role that grants access to all projects can always edit a project, even one marked read-only.

Best Practices

Decide deliberately which status carries the Complete workflow state. The Complete workflow state does more than mark a project finished. Depending on setup, it can also clear the project from a field user's mobile view, trigger completion notifications, and feed integrations. If your workflow uses an interim status (like "Submitted for Review") ahead of a final one, be intentional about which status actually gets the Complete workflow state, since that's the single trigger point for all of that behavior at once. See Workflow Types for how notifications and requirements tie into workflow states.
Vendor accounts inherit Field User permissions by default. Restricting a status with "Field User can't set this status" also restricts it for Vendor users, unless that vendor has been granted Admin permissions on their account.
Set Read-Only workflow states as the final status options. Applying a Read-Only workflow state to a status earlier in the process can lock a project before later steps, like additional photos or a final review, are complete. Reserve Read-Only for the status that marks the end of the workflow.

Project Status and Workflow States