Understanding Processes

Processes are the heart of Three Sigma. Every workflow you build, every form you deploy, every approval chain you create—it's all a process.

This page explains what processes are made of and how the pieces fit together.

What Is a Process?

A process is a structured workflow that guides work from start to finish. It defines:

• What information gets collected (fields)

• What stages work moves through (steps)

• What users can do at each stage (actions)

• What happens automatically (automations)

• How work flows based on conditions (transitions)

Think of a process as a smart form that knows what to do next.

The Building Blocks

Steps

Steps are the stages of your workflow. Each step represents a moment where someone needs to do something—fill out information, make a decision, or review work.

Example: Engineering Change Request

1. Submit Request — Engineer describes the change

2. Technical Review — Design team evaluates feasibility

3. Impact Assessment — Safety and compliance review

4. Approval — Management decision

5. Implementation — Change is executed

6. Closure — Documentation updated, stakeholders notified

Each step can have its own fields, actions, and logic. Work moves from step to step based on what users do.

Fields

Fields capture the data you need at each step. Three Sigma offers an ever-expanding rich library of field types to handle different kinds of information.

Common field types:

Example: Supplier Audit step fields

• supplierName (Text) — Company being audited

• auditDate (DateTime) — When the audit occurred

• auditType (Select) — Initial, Annual, For-Cause

• overallScore (Number) — Audit score out of 100

• findings (Note) — Detailed observations

• auditorSignature (Signature) — Auditor's formal sign-off

Actions

Actions are the buttons users click to move work forward. Every action can:

• Advance to the next step

• Route to different steps based on conditions

• Trigger automations (emails, notifications, other processes)

• Require certain fields to be completed first

Example: Quality Review step actions

Actions can be conditional—only appearing when certain conditions are met.

Transitions

Transitions define where work goes next. They connect actions to steps and can include conditions.

Simple transition:

When user clicks "Submit" → go to "Review" step

Conditional transition:

When user clicks "Complete Review":

• If overallScore >= 80 → go to "Approved" step

• If overallScore < 80 → go to "Corrective Action" step

Transitions make your process smart. Work flows differently based on the data.

Automations

Automations are things that happen automatically when actions are triggered. No user intervention needed.

Types of automations:

Example: Non-Conformance process automations

• When "Log Defect" is clicked → Email quality supervisor

• When "Disposition: Scrap" is selected → Trigger inventory adjustment process

• When "Close" is clicked → Email original submitter with resolution

How It All Fits Together

Let's walk through a complete example.

Process: Purchase Request Approval

Step 1: Submit Request

• Fields: itemDescription, quantity, estimatedCost, justification, requestor

• Actions: Submit for Approval → routes based on cost

Step 2: Manager Review (if cost < $5,000)

• Fields: managerComments, managerApproval (Signature)

• Actions:

  • Approve → goes to Procurement

  • Reject → goes to Closed (rejected)

  • Request Changes → goes back to Submit Request

Step 3: Director Review (if cost ≥ $5,000)

• Fields: directorComments, directorApproval (Signature)

• Actions: Same as Manager Review, but higher authority

Step 4: Procurement

• Fields: poNumber, vendor, actualCost, deliveryDate

• Actions: Complete → goes to Closed (approved)

Step 5: Closed

• Fields: closureDate (auto-generated), finalStatus

• No actions (end state)

Automations:

• On Submit → Email appropriate reviewer based on cost

• On Approve → Email requestor with confirmation

• On Reject → Email requestor with rejection reason

• On Complete → Trigger budget tracking process with cost data

Processes in Action: More Examples

Corrective Action (CAPA)

Steps: Issue Identification → Root Cause Analysis → Action Planning → Implementation → Effectiveness Verification → Closure

Key fields: Problem description, 5-Why analysis, action items, verification evidence, effectiveness score

Document Control

Steps: Draft → Review → Approve → Release → (optional) Revision Request

Key fields: Document number, version, content, reviewer signatures, effective date

Training Record

Steps: Assignment → Completion → Verification → Certification

Key fields: Employee, course, completion date, trainer signature, expiration date

Customer Complaint

Steps: Intake → Investigation → Response → Resolution → Follow-up

Key fields: Customer info, complaint details, root cause, response sent, satisfaction confirmation

Key Concepts

Processes are reusable Define once, run thousands of times. Each run is a "process instance" with its own data.

Fields can be conditional Mark fields as required only when certain conditions are met. A "rejection reason" field only required when rejecting.

Steps can branch and merge Processes don't have to be linear. Route to different paths and bring them back together.

Everything is audited Every field change, every action taken, every transition—logged with who, what, and when.

Next Steps
→ Fields Reference — Explore all field types
→ Automations Reference — See all automation types