Workflows

Workflows turn a Status column into a structured process engine. Instead of letting anyone freely change a row's status at any time, you define exactly which transitions are allowed, who can trigger them, what conditions must be met, and what happens automatically after a transition completes. This makes Copera boards comparable to dedicated process tools like Jira or ServiceNow — built right into your workspace.

Enabling a Workflow

Workflows are configured individually per Status column. To enable one:

1. Open your board and go to the table that contains the Status column you want to control.
2. Click the column header to open column settings.
3. Toggle the Workflow switch to on.
4. The visual workflow editor appears — a canvas showing each status as a node and each allowed transition as a directed arrow between nodes.
5. Set an Initial Status — the status that new rows start with when they are created.

tip

When you first enable workflow mode, Copera offers pre-built templates for common processes such as Software Development (Backlog → In Progress → Code Review → QA → Done), IT Service Desk, HR Onboarding, and Content Approval. Applying a template populates the statuses and transitions for you, giving you a solid starting point to customize.

Status Transitions

A transition defines an allowed path between two statuses. Without a defined transition, the status change is blocked.

Named Transitions

Each transition can have a display name that appears in the interface when users are choosing what to do next — for example, "Start Review," "Approve," or "Send Back for Revisions." Clear names help team members understand what each action means in the context of your process.

Specific Transitions

A specific transition connects one particular status to another. You draw these on the visual editor by dragging from one status node to another. For example, connecting "To Do" directly to "In Review" creates a transition that only allows that one path.

Global Transitions

A global transition originates from any status and goes to a specific target. These are useful for actions that can always happen regardless of where a row is in the process — for example, a "Cancel" transition that moves the row to "Cancelled" from wherever it currently sits, or an "Escalate" transition that works at any stage.

"From Any Status" Toggle

You can convert any specific transition into a global transition directly from the visual editor. When you click on a transition edge and open the side panel, check the "From any status" checkbox. This sets the source to "Any Status" and the edge becomes dashed, visually indicating that the transition is reachable from all statuses. Uncheck the box to restore the original specific source status.

This is especially useful when you realize during workflow design that a transition like "Cancel" or "Close" should be available from every stage — you don't need to manually draw individual edges from each status.

note

Users can always clear a status value (set it to empty) regardless of workflow rules. This is intentional: clearing a status does not count as a transition and is never blocked.

If the row has no current status yet (first assignment after creation), any allowed status can be set freely. Workflow validation only applies when changing from one defined status to another.

Conditions — Who Can Execute a Transition

Conditions control which users are permitted to trigger a given transition. All conditions on a single transition use AND logic — the user must satisfy every condition listed.

Condition Type	Description
Role	The user must hold one of the specified board roles.
User	The user must be in a specific list of named people.
Team	The user must belong to one of the specified teams in the workspace.
Row Owner	Only the user who created the row can trigger this transition.
Assignee	Only users currently assigned to the row (in a Users column) can trigger it.

note

Board admins bypass condition checks — they can trigger any transition regardless of conditions. However, admins are not exempt from validators. Data requirements apply to everyone.

Validators — What Must Be True

Validators check whether the row's data meets requirements before the transition is allowed to proceed. Unlike conditions, validators are enforced for all users, including admins.

Validator Type	Description
Field Required / Field Not Empty	A specified column must have a value. If it is empty, the transition is blocked.
Field Matches	The column's value must match a pattern you define. Useful for enforcing formats such as reference numbers or codes.

Each validator can display a custom error message so users know exactly what they need to fill in before the transition can proceed.

Required Fields

Beyond validators (which check existing data), a transition can also prompt the user to fill in fields at the moment of the transition. When required fields are configured, a dialog appears as soon as the user triggers the transition, asking for those values before the status change completes.

This is useful when you want to capture context at a specific stage — for example, requiring a "Rejection Reason" field when moving to a "Rejected" status.

Approval Gates

Transitions can require approval from designated people before the status change takes effect. When a user triggers a transition that has approval enabled, the row moves to a Pending Approval status while the approval request is processed. Once the request is resolved (approved or rejected), the row moves to the target status or back to its original status.

Approver Types

You can designate approvers in four ways:

• Specific Users — Named individuals who must review the request.
• Board Role — Anyone holding a specified role on the board (such as "Manager") becomes an approver.
• Row Owner — The person who created the row is the approver.
• Column Based — Approvers are determined dynamically based on a column value on the row (see below).

Column-Based Conditional Approvers

Column-based approval lets you route approval requests to different people depending on a value in the row — without creating separate transitions or workflows for each case.

When you select Column Based as the approver type, three configuration options appear:

1. Condition column — Choose a Dropdown (SELECT) column from the table. The current value of this column on the row determines who the approvers will be.
2. Mapping table — For each option in the selected column, assign one or more approvers. For example, if your "Department" column has options "RH," "Systems," and "Finance," you can map each department to its respective manager.
3. Fallback approvers — Optional users who receive the approval request when the row's column value does not match any mapping (or the column is empty).

Example — Multi-level departmental approval:

Suppose you have a "Department" column with options RH, Systems, and Finance. You can configure two transitions:

• Open → In Review: Column-based approval on "Department" — maps RH to Manager A, Systems to Manager B
• In Review → Done: Column-based approval on "Department" — maps RH to Director X, Systems to Director Y

Each transition independently resolves the correct approver for the row's department. This creates a multi-level approval flow where department managers approve first, and then department directors approve next.

tip

The requester (the person who triggered the transition) is automatically excluded from the approver list, even if they match the mapping. A person cannot approve their own request.

Approval Policies

Policy	Behavior
ANY_ONE	The first approver to act (approve or reject) resolves the request for everyone.
ALL	Every designated approver must approve. A single rejection rejects the entire request.

Pending Approval Status

When approval is enabled on a transition, the system automatically creates a Pending Approval status option on the column. This is a real status — not a hidden internal state — which means it works seamlessly with every feature in Copera:

• Filters: Filter your table to see only rows waiting for approval.
• Kanban view: A "Pending Approval" column appears automatically, grouping all rows awaiting decisions.
• SLA timers: Configure SLA conditions to start timing when a row enters the pending status and pause when it exits.
• Automations: Create automations that trigger when a row's status changes to "Pending Approval" (for example, auto-assign a reviewer or send a custom notification).
• Per-status visibility and field rules: Configure visibility and field behavior overrides specifically for the pending state.

The pending status appears in the visual editor as a distinct node with an amber border and hourglass icon, making it easy to identify in your workflow graph.

note

Pending approval statuses are managed by the system. They cannot be renamed or deleted manually — they are created when you enable approval on a transition and cleaned up automatically when you disable it.

How the flow works:

1. A user triggers a transition that requires approval (e.g., Open → In Review).
2. The row immediately moves to the Pending Approval status.
3. The designated approvers receive a notification.
4. If approved: the row moves to the target status (In Review).
5. If rejected: the row moves to the configured rejection status, or back to the original status (Open) if none is set.

If you have multiple transitions with approval enabled, each gets its own pending status (e.g., "Pending: Manager Approval" and "Pending: Director Approval"), so you can distinguish between different approval stages.

Rejection Handling

When a transition is rejected, you can configure what happens to the row:

• Move it to a specific status (for example, a "Rejected" or "Needs Revision" status).
• If no rejection status is configured, the row moves back to the status it was in before the approval was triggered.

Notifications

Both the requester and the designated approvers receive in-app and email notifications. Approvers are notified when a new approval request is waiting for them; the requester is notified when their request is approved or rejected.

Comments on Approval Decisions

Approvers can add a comment alongside their decision. You can configure a transition to require a comment when rejecting, ensuring that feedback is always documented.

note

Only one approval request per row per Status column can be pending at a time. If a request is already pending, no new transition can be triggered until it is resolved or cancelled.

Post-Transition Functions

Post-transition functions are actions that execute automatically after a transition successfully completes (including after an approval is granted, if applicable). They run without any user interaction.

Function	Description
Set Field	Set a column to a specific static value.
Copy Field	Copy the value from one column into another column on the same row.
Set Current Date	Write the current date and time into a date column — useful for timestamping when a transition happened.
Assign Current User	Add the user who triggered the transition to a Users column.
Assign User	Add one or more specific people to a Users column.
Clear Field	Remove the value from a column entirely.
Send Notification	Send an in-app notification to specific users with a custom message.
Webhook	Send an HTTP request (POST, PUT, or PATCH) to an external URL, enabling integration with third-party systems.

You can add multiple post-functions to a single transition, and they execute in the order they are listed.

Per-Status Visibility

You can control which users are allowed to see rows based on the row's current status. This is configured by clicking a status node in the visual editor and opening its settings panel.

Visibility Setting	Description
Role-based	Only users with specific board roles can see rows in this status.
User-based	Only specific named users can see rows in this status.
Owner Can View	The row's creator always sees their own rows, even if visibility rules would otherwise exclude them. Enabled by default.
Assignee Can View	Users assigned to the row always see it. Enabled by default.

note

Board admins always see all rows regardless of visibility rules. Visibility settings only apply to regular members and guests.

Per-Status Field Behavior

When a row is in a given status, you can override how individual fields behave. This is also configured from the status node settings panel.

Behavior	Description
Editable	Normal behavior — the field can be read and modified. This is the default.
Read-only	The field is visible but cannot be edited. Admins can still edit read-only fields.
Required	The field must have a value. This is enforced for all users including admins — it is a data integrity rule, not a permission restriction.
Hidden	The field is not visible to non-admins and is excluded from API responses. Admins can still see and edit hidden fields.

SLA Timers

Workflow status transitions can automatically start, pause, and stop SLA timer columns. When a row moves into or out of specific statuses, the timer responds accordingly — enabling automatic tracking of how long work spends in each stage. See the SLA Tracking page for full configuration details.

Tips

• Start simple. Enable workflow with a few basic transitions first, then layer in conditions, validators, and approval gates as your process matures.
• Use the visual editor to map your process. Draw out the flow on the canvas before adding rules — it is much easier to catch gaps and loops visually.
• Global transitions are great for exceptions. "Cancel," "Escalate," or "Emergency Close" actions that should always be available from any status work perfectly as global transitions (from ANY).
• Combine approval gates with per-status visibility. Move a row into a "Pending Review" status that only reviewers can see, and require their approval before it advances. This creates a secure, auditable review process.
• Use post-functions for repetitive updates. Automatically timestamp completions, assign the person who closed a ticket, and clear temporary fields — without anyone having to remember to do it manually.
• Test with a sample row. Before rolling out a workflow to your full team, walk through the process with one test row to verify each transition, condition, and approval behaves as expected.

Next Steps

• Explore Automations for event-driven "when this happens, do that" rules that complement workflow transitions.
• Review Board Permissions to understand how board roles interact with workflow conditions.
• Learn about Field Types to understand which column types work with validators and post-functions.