Workflow Examples
This page provides complete, working examples of workflows you can use as starting points for your own processes.
Basic Approval Workflow
A simple two-step approval process with a human review:
apiVersion: pidima.ai/v1
name: Simple Approval
description: Basic request approval with manager review
trigger:
type: manual
name: Submit Request
fields:
- name: request_title
type: string
required: true
description: Brief title of the request
- name: description
type: string
required: true
description: Detailed description
- name: amount
type: number
description: Budget amount if applicable
nodes:
- id: manager_review
type: HUMAN_TASK
name: Manager Review
purpose: Manager reviews and decides on the request
inputs: [request_title, description, amount]
outputs:
- name: decision
type: string
- name: feedback
type: string
- id: approved
type: END
name: Request Approved
purpose: The request was approved
status: APPROVED
- id: rejected
type: END
name: Request Rejected
purpose: The request was rejected
status: REJECTED
connections:
- from: start
to: manager_review
- from: manager_review
to: approved
- from: manager_review
to: rejected
Multi-Level Approval Based on Amount
Automatically route requests based on amount thresholds:
apiVersion: pidima.ai/v1
name: Tiered Approval Process
description: Route approvals based on request amount
trigger:
type: manual
name: New Purchase Request
fields:
- name: item_description
type: string
required: true
- name: vendor
type: string
required: true
- name: amount
type: number
required: true
description: Total purchase amount in USD
nodes:
- id: route_by_amount
type: DECISION
name: Route by Amount
purpose: Determine approval path based on purchase amount
inputs: [amount]
branches:
- id: auto
label: Auto-Approve
when: "amount <= 500"
- id: manager
label: Manager Approval
when: "amount <= 5000"
- id: director
label: Director Approval
when: "amount <= 25000"
- id: exec
label: Executive Approval
isDefault: true
- id: manager_approval
type: HUMAN_TASK
name: Manager Approval
purpose: Department manager reviews the purchase
inputs: [item_description, vendor, amount]
outputs:
- name: approved
type: boolean
- name: notes
type: string
- id: director_approval
type: HUMAN_TASK
name: Director Approval
purpose: Director reviews high-value purchases
inputs: [item_description, vendor, amount]
outputs:
- name: approved
type: boolean
- name: notes
type: string
- id: exec_approval
type: HUMAN_TASK
name: Executive Approval
purpose: C-level approval for major purchases
inputs: [item_description, vendor, amount]
outputs:
- name: approved
type: boolean
- name: notes
type: string
- id: approved
type: END
name: Purchase Approved
purpose: Purchase request approved
status: APPROVED
- id: rejected
type: END
name: Purchase Rejected
purpose: Purchase request rejected
status: REJECTED
connections:
- from: start
to: route_by_amount
- from: route_by_amount
to: approved
branch: auto
- from: route_by_amount
to: manager_approval
branch: manager
- from: route_by_amount
to: director_approval
branch: director
- from: route_by_amount
to: exec_approval
branch: exec
- from: manager_approval
to: approved
- from: manager_approval
to: rejected
- from: director_approval
to: approved
- from: director_approval
to: rejected
- from: exec_approval
to: approved
- from: exec_approval
to: rejected
Document Review with AI Analysis
Use AI to analyze documents before human review:
apiVersion: pidima.ai/v1
name: Contract Review
description: AI-assisted contract review with legal team approval
trigger:
type: manual
name: Submit Contract
fields:
- name: contract_title
type: string
required: true
- name: counterparty
type: string
required: true
- name: contract_type
type: string
required: true
- name: contract_document
type: object
required: true
description: The contract document to review
nodes:
- id: ai_analysis
type: BUSINESS_STEP
name: AI Contract Analysis
purpose: Analyze contract for risks and key terms
inputs: [contract_document, contract_type]
operations:
- type: ai_extract
prompt: |
Analyze this {{contract_type}} contract and extract:
1. Key terms and conditions
2. Potential risks or unusual clauses
3. Missing standard provisions
4. Recommended negotiation points
input: contract_document
into: analysis_result
outputs:
- name: key_terms
type: array
- name: identified_risks
type: array
- name: risk_score
type: number
- name: recommendations
type: array
- id: risk_routing
type: DECISION
name: Route by Risk
purpose: Determine review level based on AI risk assessment
inputs: [risk_score]
branches:
- id: high_risk
label: High Risk - Senior Review
when: "risk_score >= 70"
- id: standard
label: Standard Review
isDefault: true
- id: legal_review
type: HUMAN_TASK
name: Legal Review
purpose: Legal team reviews contract and AI findings
inputs: [contract_document, key_terms, identified_risks, recommendations]
outputs:
- name: decision
type: string
- name: required_changes
type: array
- name: approval_conditions
type: string
- id: senior_legal_review
type: HUMAN_TASK
name: Senior Legal Review
purpose: Senior counsel reviews high-risk contracts
inputs: [contract_document, key_terms, identified_risks, recommendations]
outputs:
- name: decision
type: string
- name: required_changes
type: array
- name: approval_conditions
type: string
- id: approved
type: END
name: Contract Approved
purpose: Contract approved for signature
status: APPROVED
- id: needs_revision
type: END
name: Needs Revision
purpose: Contract requires changes before approval
status: REVISION_REQUIRED
- id: rejected
type: END
name: Contract Rejected
purpose: Contract rejected - do not proceed
status: REJECTED
connections:
- from: start
to: ai_analysis
- from: ai_analysis
to: risk_routing
- from: risk_routing
to: senior_legal_review
branch: high_risk
- from: risk_routing
to: legal_review
branch: standard
- from: legal_review
to: approved
- from: legal_review
to: needs_revision
- from: legal_review
to: rejected
- from: senior_legal_review
to: approved
- from: senior_legal_review
to: needs_revision
- from: senior_legal_review
to: rejected
Customer Onboarding with External Integrations
A workflow that integrates with external systems:
apiVersion: pidima.ai/v1
name: Customer Onboarding
description: Automated customer onboarding with KYC verification
trigger:
type: manual
name: New Customer Application
fields:
- name: company_name
type: string
required: true
- name: contact_email
type: string
required: true
- name: contact_name
type: string
required: true
- name: business_type
type: string
required: true
- name: tax_id
type: string
required: true
- name: documents
type: array
description: Supporting documents
nodes:
- id: verify_identity
type: BUSINESS_STEP
name: Identity Verification
purpose: Verify business identity through external services
inputs: [company_name, tax_id]
tools:
- capability: verify_business
connection: kyc-provider
action: business_verification
args:
business_name: "{{company_name}}"
tax_id: "{{tax_id}}"
rules:
- id: KYC1
name: Verification passed
priority: 1
condition: "kyc_status == 'verified'"
outcome: VERIFIED
- id: KYC2
name: Verification failed
priority: 2
condition: "true"
outcome: FAILED
outputs:
- name: kyc_status
type: string
- name: kyc_score
type: number
- name: kyc_flags
type: array
- id: kyc_decision
type: DECISION
name: KYC Decision
purpose: Route based on verification results
inputs: [kyc_status, kyc_flags]
branches:
- id: passed
label: KYC Passed
when: "kyc_status == 'verified' && kyc_flags.length == 0"
- id: review
label: Manual Review
when: "kyc_status == 'verified'"
- id: failed
label: KYC Failed
isDefault: true
- id: compliance_review
type: HUMAN_TASK
name: Compliance Review
purpose: Manual review of flagged applications
inputs: [company_name, kyc_status, kyc_flags, documents]
outputs:
- name: decision
type: string
- name: notes
type: string
- id: create_account
type: ACTION
name: Create Customer Account
purpose: Provision customer account in CRM
inputs: [company_name, contact_email, contact_name]
tools:
- capability: create_customer
connection: crm
action: create_account
args:
name: "{{company_name}}"
primary_contact: "{{contact_name}}"
email: "{{contact_email}}"
outputs:
- name: account_id
type: string
- id: send_welcome
type: ACTION
name: Send Welcome Package
purpose: Send onboarding materials to new customer
inputs: [contact_email, contact_name, account_id]
tools:
- capability: send_email
connection: email-service
action: send_template
args:
template: "customer_welcome"
to: "{{contact_email}}"
variables:
name: "{{contact_name}}"
account_id: "{{account_id}}"
- id: onboarded
type: END
name: Customer Onboarded
purpose: Customer successfully onboarded
status: ONBOARDED
- id: rejected
type: END
name: Application Rejected
purpose: Customer application rejected
status: REJECTED
connections:
- from: start
to: verify_identity
- from: verify_identity
to: kyc_decision
- from: kyc_decision
to: create_account
branch: passed
- from: kyc_decision
to: compliance_review
branch: review
- from: kyc_decision
to: rejected
branch: failed
- from: compliance_review
to: create_account
- from: compliance_review
to: rejected
- from: create_account
to: send_welcome
- from: send_welcome
to: onboarded
requiredSystems:
- key: kyc-provider
kind: REST_API
purpose: Business identity verification
- key: crm
kind: SALESFORCE
purpose: Customer account management
- key: email-service
kind: SMTP
purpose: Email communications
Incident Response with Escalation
An IT incident response workflow with SLA-based escalation:
apiVersion: pidima.ai/v1
name: Incident Response
description: IT incident handling with SLA-driven escalation
trigger:
type: webhook
name: Incident Reported
fields:
- name: incident_title
type: string
required: true
- name: description
type: string
required: true
- name: severity
type: string
required: true
- name: affected_systems
type: array
- name: reporter_email
type: string
nodes:
- id: categorize
type: BUSINESS_STEP
name: Categorize Incident
purpose: Determine incident priority and routing
inputs: [severity, affected_systems]
parameters:
critical_systems: ["payment", "auth", "database"]
rules:
- id: CAT1
name: Critical - Production Down
priority: 1
condition: "severity == 'critical' || affected_systems.some(s => critical_systems.includes(s))"
outcome: P1
- id: CAT2
name: High - Major Impact
priority: 2
condition: "severity == 'high'"
outcome: P2
- id: CAT3
name: Standard
priority: 3
condition: "true"
outcome: P3
outputs:
- name: priority
type: string
- name: sla_hours
type: number
- id: priority_routing
type: DECISION
name: Route by Priority
purpose: Direct incident to appropriate response team
inputs: [priority]
branches:
- id: p1
label: Critical Response
when: "priority == 'P1'"
- id: p2
label: Urgent Response
when: "priority == 'P2'"
- id: p3
label: Standard Queue
isDefault: true
- id: critical_response
type: HUMAN_TASK
name: Critical Incident Response
purpose: Immediate response for critical incidents
inputs: [incident_title, description, affected_systems]
outputs:
- name: resolution_status
type: string
- name: root_cause
type: string
- name: resolution_notes
type: string
- id: page_oncall
type: ACTION
name: Page On-Call Team
purpose: Alert on-call engineers immediately
inputs: [incident_title, severity, affected_systems]
tools:
- capability: send_alert
connection: pagerduty
action: create_incident
args:
title: "{{incident_title}}"
urgency: "high"
body: "Affected systems: {{affected_systems}}"
- id: standard_response
type: HUMAN_TASK
name: Standard Incident Response
purpose: Handle non-critical incidents
inputs: [incident_title, description]
outputs:
- name: resolution_status
type: string
- name: resolution_notes
type: string
- id: sla_wait
type: WAIT
name: SLA Check
purpose: Monitor SLA compliance
waitFor: SLA deadline
waitHours: 4
- id: escalate
type: ACTION
name: Escalate Incident
purpose: Escalate unresolved incidents
inputs: [incident_title, priority, sla_hours]
tools:
- capability: escalate
connection: pagerduty
action: escalate_incident
- id: resolved
type: END
name: Incident Resolved
purpose: Incident successfully resolved
status: RESOLVED
- id: escalated
type: END
name: Incident Escalated
purpose: Incident escalated to management
status: ESCALATED
connections:
- from: start
to: categorize
- from: categorize
to: priority_routing
- from: priority_routing
to: page_oncall
branch: p1
- from: page_oncall
to: critical_response
- from: priority_routing
to: standard_response
branch: p2
- from: priority_routing
to: standard_response
branch: p3
- from: critical_response
to: resolved
- from: standard_response
to: resolved
- from: standard_response
to: sla_wait
- from: sla_wait
to: escalate
- from: escalate
to: escalated
requiredSystems:
- key: pagerduty
kind: REST_API
purpose: Incident alerting and escalation
Minimal Starter Template
The simplest possible workflow to start with:
apiVersion: pidima.ai/v1
name: My Workflow
description: What this process does, in one sentence.
trigger:
type: manual
name: Start
fields:
- name: reference
type: string
required: true
description: What the case is about
nodes:
- id: process
type: BUSINESS_STEP
name: Process The Case
purpose: Do the main work of this workflow
inputs: [reference]
outputs:
- name: result
type: string
- id: done
type: END
name: Complete
purpose: The workflow is finished
status: COMPLETED
connections:
- from: start
to: process
- from: process
to: done
Tips for Writing Workflows
Keep It Business-Focused
Node names and purposes should describe what happens in business terms, not how it's implemented:
# Good
- id: verify_eligibility
name: Verify Applicant Eligibility
purpose: Confirm the applicant meets minimum requirements
# Avoid
- id: step_1
name: Call API and Check Response
purpose: Make HTTP request to endpoint
Use Meaningful IDs
IDs should be readable and indicate the step's purpose:
# Good
connections:
- from: risk_assessment
to: underwriter_review
# Avoid
connections:
- from: node_3
to: node_4
Document Parameters
Include descriptions for parameters so business users understand what they control:
parameters:
# Amount below which orders auto-approve
auto_approve_threshold: 1000
# Maximum days to wait for customer response
response_deadline_days: 7
# Regions eligible for express processing
express_regions: ["US", "CA"]
Design for Visibility
Ensure the workflow shows meaningful status at each step:
outputs:
- name: decision
type: string
description: APPROVED, REJECTED, or NEEDS_REVIEW
- name: decision_reason
type: string
description: Explanation of the decision
Next Steps
- Read the DSL Reference for complete field documentation
- Try the workflow editor at
/studio/importin Pidima Studio - Learn about MCP Integration for programmatic workflow creation