Workflows

Turn your standard operating procedures into visual, enforceable workflows. This comprehensive guide covers everything from basic workflow concepts to advanced automation patterns.

Overview

Workflows in MovaLab automate your business processes. Instead of relying on tribal knowledge and scattered SOPs, create visual processes that guide work through your organization with built-in accountability.

Visual Builder

Drag-and-drop workflow designer with real-time preview

Automated Routing

Work automatically moves between steps based on rules

Department Handoffs

Seamless transitions between teams (Design → Dev)

Approval Chains

Built-in approval workflows with escalation

Conditional Logic

If/then branching based on data and responses

Audit Trail

Complete history of every step and decision

Why Use Workflows?

Workflows ensure consistency, reduce errors, and provide visibility. Instead of asking "where is this project?" everyone can see exactly where work is in the process.

Core Concepts

Understanding these concepts is essential for building effective workflows.

Workflow Template

A workflow template is the reusable blueprint. It defines the steps, transitions, and rules. Templates can be applied to projects, tasks, or other entities.

Template: "Website Project Workflow"
├── Nodes (Steps)
├── Transitions (Connections)
├── Conditions (Rules)
└── Actions (Automations)

Can be applied to:
- Projects
- Tasks
- Approvals
- Custom entities

Workflow Instance

An instance is a running workflow. When you apply a template to a project, you create an instance. Each instance tracks its own state and progress.

Instance: "Acme Corp Website Redesign"
├── Template: "Website Project Workflow"
├── Current Node: "Development"
├── Started: 2024-01-15
├── Assigned: Engineering Team
└── History: [Discovery → Design → Development]

Node (Step)

Nodes are individual steps in the workflow. Each node has a type (task, approval, decision, etc.), assigned roles, and configuration.

StartEntry point

TaskWork step

DecisionBranch point

EndCompletion

Transition

Transitions connect nodes and define how work moves between steps. They can be automatic (based on conditions) or manual (requiring user action).

[Design] ──────────────────► [Development]
         Transition Config:
         - Trigger: "Design Approved"
         - Condition: approval.status === 'approved'
         - Action: Notify dev team
         - Auto-assign: Engineering Lead

Building Workflows

Access the workflow builder from Settings → Workflows → Create Workflow or clone an existing template.

Step-by-Step: Creating a Workflow

Name and Describe

Give your workflow a clear name (e.g., 'Client Onboarding') and description explaining when it's used.

Add Start Node

Every workflow begins with a Start node. Configure what triggers the workflow (manual, on project create, etc.).

Define Steps

Add Task nodes for each step. Assign roles, set descriptions, and configure any required fields or forms.

Connect Nodes

Draw transitions between nodes. Click and drag from one node's output to another's input.

Add Conditions

For decision points, add conditions that determine which path to take. Use data from forms, task status, etc.

Configure Actions

Set up automated actions: notifications, field updates, external webhooks, assignment changes.

Add End Node(s)

Add End nodes for each completion state (e.g., 'Completed', 'Cancelled'). Multiple end states are supported.

Test and Publish

Use the preview mode to test your workflow. Once validated, publish to make it available.

Workflow Builder Interface

┌─────────────────────────────────────────────────────────┐
│  Workflow: Client Onboarding            [Save] [Publish]│
├─────────────────────────────────────────────────────────┤
│  ┌─────────┐                                            │
│  │ Nodes   │   ┌───────────────────────────────────┐    │
│  ├─────────┤   │                                   │    │
│  │ ○ Start │   │   [Start] ──► [Kickoff] ──► [?]   │    │
│  │ □ Task  │   │                             │     │    │
│  │ ◇ Decision   │               ┌────────────┴───┐  │    │
│  │ ○ Approval │ │               ▼                ▼  │    │
│  │ ◉ End   │   │         [Design]        [Rush]  │    │
│  └─────────┘   │               │              │   │    │
│                │               ▼              ▼   │    │
│  ┌─────────┐   │         [Development] ◄─────┘   │    │
│  │ Actions │   │               │                  │    │
│  ├─────────┤   │               ▼                  │    │
│  │ Notify  │   │           [Review]               │    │
│  │ Assign  │   │               │                  │    │
│  │ Update  │   │               ▼                  │    │
│  │ Webhook │   │            [End]                 │    │
│  └─────────┘   └───────────────────────────────────┘    │
└─────────────────────────────────────────────────────────┘

Node Types

Each node type serves a specific purpose in your workflow. Choose the right type for each step.

Start Node

Entry point of the workflow. Defines how and when the workflow begins.

Trigger Options:

• Manual start
• On entity create (project/task)
• On status change
• Scheduled (cron)
• Webhook trigger

Configuration:

• Initial assignee
• Required input data
• Entry conditions
• Initial form

Task Node

A work step that requires action. Assigned to a user or role, with optional due dates and forms.

Assignment Options:

• Specific user
• Role (e.g., "Designer")
• Department
• Previous step assignee
• Project owner
• Round-robin

Task Options:

• Due date (fixed or relative)
• Required fields/forms
• Attachments required
• Checklist items
• Time estimate
• SLA/escalation

Approval Node

Pauses workflow until approval is granted. Supports multiple approvers and escalation.

Approval Types:

• Single approver
• Any of multiple (first wins)
• All must approve
• Majority approval
• Sequential chain
• Client approval

Outcomes:

• Approved → continue
• Rejected → route to revision
• Request changes → loop back
• Escalate → notify manager
• Timeout → auto-action

Decision Node

Branches the workflow based on conditions. Evaluates data and routes to different paths.

Decision: "Project Type"
├── If project.budget > 50000
│   └── Route to: "Enterprise Flow"
├── If project.type === "rush"
│   └── Route to: "Rush Flow"
└── Default
    └── Route to: "Standard Flow"

Parallel Node (Fork/Join)

Splits workflow into parallel branches that execute simultaneously. Join node waits for all to complete.

        [Fork]
       /   |   \
[Design] [Copy] [Dev Setup]
       \   |   /
        [Join]
           |
       [Review]

Delay Node

Pauses workflow for a specified duration. Useful for waiting periods, review windows, or scheduled actions.

Delay Types:

• Fixed duration (e.g., 2 days)
• Until specific date
• Until business hours
• Until condition met

Use Cases:

• Client review period
• Cooling off period
• Scheduled launch
• Follow-up reminders

End Node

Terminates the workflow. Multiple end nodes support different completion states.

Completed

Successfully finished

Cancelled

Terminated early

On Hold

Paused indefinitely

Transitions

Transitions define how work moves between nodes. They can be triggered automatically or require manual action.

Transition Types

Automatic Transition

Triggers immediately when the source node completes. No user action required.

Task complete → Next task

Manual Transition

User must explicitly select this transition. Shows as action button.

"Submit for Review" button

Conditional Transition

Only available when conditions are met. Conditions evaluated at runtime.

If budget > $10k → Executive approval

Timed Transition

Triggers after specified duration if no other transition taken.

Auto-escalate after 48 hours

Transition Configuration

Transition: "Design Complete → Development"

├── Trigger
│   ├── Type: "On task completion"
│   └── Button Label: "Send to Development"
│
├── Conditions (all must be true)
│   ├── designFiles.length > 0
│   ├── clientApproval.status === 'approved'
│   └── form.designSpec.complete === true
│
├── Actions (execute on transition)
│   ├── Notify: development_team
│   ├── Assign: engineering_lead
│   ├── Update: project.status = 'in_development'
│   └── Webhook: notify-external-system
│
└── Validation
    ├── Required fields complete
    └── No blocking issues open

Conditions & Logic

Conditions control when transitions are available and how decision nodes route work.

Condition Syntax

// Available Variables
project.{field}      // Project data
task.{field}         // Current task data
form.{formId}.{field} // Form responses
user.{field}         // Current user
assignee.{field}     // Task assignee
account.{field}      // Parent account
workflow.{field}     // Workflow instance data

// Operators
===  // Equals
!==  // Not equals
>    // Greater than
<    // Less than
>=   // Greater or equal
<=   // Less or equal
&&   // AND
||   // OR
!    // NOT

// Examples
project.budget > 50000
task.status === 'complete' && form.review.approved === true
account.tier === 'enterprise' || project.priority === 'urgent'
!task.blockers.length  // No blockers

Common Condition Patterns

Budget-Based Routing

project.budget >= 100000

Route to executive approval

Priority Escalation

project.priority === 'urgent' && !task.assignee

Auto-assign to lead

Client Tier

account.tier === 'enterprise'

Use premium workflow

Deadline Check

daysUntilDeadline(project.dueDate) < 3

Skip optional steps

Approval Status

form.clientReview.status === 'approved'

Proceed to next phase

Team Availability

department.capacity > 20

Route to available team

Triggers

Triggers determine what starts a workflow or moves it to the next step.

Workflow Start Triggers

Manual

User clicks 'Start Workflow' button

Entity Create

Automatically when project/task is created

Status Change

When entity status changes to specific value

Scheduled

Runs on a schedule (daily, weekly, etc.)

Webhook

External system triggers via API

Form Submit

When a specific form is submitted

Transition Triggers

Trigger	Description	Example
on_complete	Task marked complete	Design task done → Dev task
on_approve	Approval granted	Client approves → Continue
on_reject	Approval rejected	Rejected → Back to design
on_timeout	Time limit exceeded	48hr timeout → Escalate
on_condition	Condition becomes true	All files uploaded → Review
manual	User clicks button	"Send to Dev" button

Actions

Actions execute automatically when nodes complete or transitions fire. Chain multiple actions together.

Available Actions

Send Notification

Email, in-app, or push notification to users or roles

Assign User

Assign task to specific user, role, or by rule

Send Email

Send templated email to any recipient

Post Comment

Add comment to project, task, or entity

Update Field

Set or update field values on entity

Start Workflow

Trigger another workflow

Create Task

Generate new task with predefined settings

Webhook

Call external API with payload

Action Configuration Example

On Transition: "Design Complete → Development"

Actions:
1. Send Notification
   - To: role:engineering_lead
   - Title: "New project ready for development"
   - Message: "{{project.name}} design is complete"
   - Link: {{project.url}}

2. Assign User
   - Task: next_node
   - Assign To: role:senior_developer
   - Method: round_robin

3. Update Field
   - Entity: project
   - Field: status
   - Value: "in_development"

4. Send Email
   - To: {{project.client_email}}
   - Template: "design_approved"
   - Variables: { project_name, estimated_delivery }

5. Webhook
   - URL: https://api.slack.com/webhook/xxx
   - Method: POST
   - Body: { "text": "{{project.name}} moving to dev" }

Workflow Templates

Start with pre-built templates and customize for your needs. Templates can be shared across the organization.

Built-in Templates

Client Onboarding

Kickoff → Discovery → Setup → Training → Handoff

New client setup process

Website Project

Discovery → Design → Development → QA → Launch

Full website build lifecycle

Content Approval

Draft → Review → Revisions → Final Approval → Publish

Content review process

Bug Fix

Reported → Triaged → In Progress → Testing → Deployed

Bug tracking and resolution

Feature Request

Submitted → Review → Approved? → Scheduled → Delivered

Feature request handling

Employee Onboarding

Hired → Paperwork → Setup → Training → 30-day Check

New employee process

Managing Templates

Clone Template

Duplicate existing template as starting point

Export Template

Download as JSON for backup or sharing

Import Template

Upload JSON template from file

Version Control

Templates track version history with rollback

Set as Default

Automatically apply to new projects of type

Best Practices

Start Simple

Begin with basic workflows and add complexity as needed. A 5-step workflow that's actually used beats a 20-step workflow that's ignored.

Map Your Current Process First

Document how work actually flows today before building. Workflows should reflect reality, not idealized processes.

Assign Roles, Not People

Use roles (e.g., 'Designer') instead of specific users. This makes workflows resilient to team changes.

Set Realistic SLAs

Build in buffer time. If a step usually takes 2 days, set the SLA to 3. Under-promising and over-delivering builds trust.

Use Descriptive Names

Name nodes clearly: 'Initial Design Review' not 'Step 3'. Future you will thank present you.

Test Before Deploying

Run test instances through the workflow. Check all paths, especially error cases and edge conditions.

Plan for Exceptions

Build in escape hatches. Not every project fits the happy path. Allow manual overrides with audit logging.

Review and Iterate

Analyze workflow metrics monthly. Where do things get stuck? Which steps take too long? Continuously improve.

Common Mistakes

• Over-automating: Some steps need human judgment
• No escape hatch: Workflows that can't be bypassed frustrate users
• Too many approvals: Every approval adds delay
• Ignoring feedback: Users will find workarounds if the workflow doesn't serve them

Complete Examples

Full workflow examples you can adapt for your organization.

Website Project Workflow

Complete website project from kickoff to launch with client approval gates.

[Start: Project Created]
        │
        ▼
[Discovery Call] ─── assigned: Account Manager
        │            duration: 1 day
        ▼
[Requirements Doc] ── assigned: Strategist
        │             form: requirements_template
        │             duration: 3 days
        ▼
[Client Approval: Scope] ── approval: client
        │                    timeout: 5 days → escalate
        ▼
  ┌─────┴─────┐
  │           │
[Approved] [Changes Requested]
  │           │
  │           └──► [Revise Requirements] ──┐
  │                                        │
  ▼                                        │
[Design Phase] ◄───────────────────────────┘
        │         assigned: Design Lead
        │         creates: design_tasks
        ▼
[Client Approval: Design]
        │
  ┌─────┴─────┐
  │           │
[Approved] [Changes Requested]
  │           │
  │           └──► [Design Revisions] ──┐
  │                                     │
  ▼                                     │
[Development] ◄─────────────────────────┘
        │       assigned: Engineering Lead
        │       parallel: true
        ├──► [Frontend Dev]
        ├──► [Backend Dev]
        └──► [QA Setup]
             │
             ▼
        [Join: Dev Complete]
             │
             ▼
        [QA Testing]
             │
         ┌───┴───┐
     [Pass]    [Fail]
         │       │
         │       └──► [Bug Fixes] ──┐
         │                          │
         ▼                          │
[Client UAT] ◄──────────────────────┘
         │
  ┌──────┴──────┐
  │             │
[Approved]   [Issues]
  │             │
  │             └──► [Address Issues] ──┐
  │                                     │
  ▼                                     │
[Launch Prep] ◄─────────────────────────┘
         │
         ▼
[Go Live]
         │
         ▼
[30-Day Support]
         │
         ▼
[End: Project Complete]

Nodes: 15

Approvals: 4

Avg Duration: 6-8 weeks

Content Approval Workflow

Multi-stage content review with conditional routing based on content type.

[Start: Content Created]
        │
        ▼
[Draft Content] ── assigned: Content Creator
        │          form: content_brief
        ▼
[Decision: Content Type]
        │
  ┌─────┼─────────┐
  │     │         │
[Blog] [Social]  [Press]
  │     │         │
  ▼     │         ▼
[Editor │    [Legal Review]
Review] │         │
  │     │         ▼
  │     │    [PR Manager
  │     │      Approval]
  │     │         │
  ▼     ▼         ▼
[Merge: Review Complete]
        │
        ▼
[Final Polish]
        │
        ▼
[Manager Approval]
        │
  ┌─────┴─────┐
  │           │
[Approved] [Rejected]
  │           │
  │           └──► [Revisions] ──► [Back to Review]
  │
  ▼
[Schedule/Publish]
        │
        ▼
[End: Published]

Simple Approval Chain

Lightweight approval workflow for budget requests or simple sign-offs.

[Start: Request Submitted]
        │
        ▼
[Decision: Amount]
        │
  ┌─────┴─────┐
  │           │
[< $1000]  [>= $1000]
  │           │
  ▼           ▼
[Manager    [Director
Approval]   Approval]
  │           │
  │           ▼
  │        [CFO Approval]
  │           │ (if > $10000)
  ▼           ▼
[Merge]◄──────┘
  │
  ▼
[Process Request]
  │
  ▼
[End: Complete]

Monitoring & Debugging

Track workflow performance and troubleshoot issues.

Workflow Analytics

Average Cycle Time

How long workflows take to complete

Bottleneck Analysis

Which steps have the longest wait times

Completion Rate

Percentage of workflows that finish vs. stall

SLA Compliance

How often deadlines are met per step

Debugging Tools

Instance History

View complete timeline of workflow execution with timestamps

Node Inspector

See current state, assignee, and data at each node

Condition Evaluator

Test conditions with sample data before deploying

Action Logs

View all actions executed and their results

Error Alerts

Get notified when workflows fail or stall