Approval Types and Step Types

This document describes all the available approval types and step types in ApprovalML, and how they behave in workflows.

Step Types

1. decision - Standard Approval Step

• Purpose: Single approver with approve/reject actions
• Behavior: Blocks workflow until action is taken
• Actions Available: Approve, Reject, Request More Information
• Use Case: Manager approvals, final decisions

2. parallel_approval - Multiple Approvers

• Purpose: Multiple approvers can work simultaneously
• Behavior: All approvers must complete (or configured strategy)
• Actions Available: Approve, Reject, Request More Information
• Use Case: Team reviews, committee approvals

3. conditional_split - Dynamic Routing

• Purpose: Route workflow based on form data or conditions
• Behavior: Automatically processes and routes to next step
• Actions Available: None (automatic)
• Use Case: Amount-based routing, department-specific flows

4. automatic - System Processing

• Purpose: System performs actions without human intervention
• Behavior: Automatically completes and continues
• Actions Available: None (automatic)
• Use Case: Data processing, system integrations, notifications

5. notification_only - Non-blocking Notification

• Purpose: Send notifications without requiring action
• Behavior: Automatically completes and continues
• Actions Available: None (automatic)
• Use Case: FYI notifications, status updates

Approval Types

1. needs_to_approve (Default)

Recipients with this role type... can do the following:

• Approve will move the workflow to the next recipient (if any)
• Decline will send the workflow back to the requestor for re-submission
• Request More Information will also send the workflow back to the requestor for re-submission

YAML Example:

manager_approval:
  name: "manager_approval"
  type: "decision"
  approver: "${requestor.manager}"
  approval_type: "needs_to_approve"  # Optional, this is the default
  on_approve:
    continue_to: "next_step"
  on_reject:
    end_workflow: true

2. needs_to_sign

Recipients with this role type... can do the following:

• Provide Signature will capture the recipient's signature and move the workflow to the next recipient (if any)
• Decline will send the workflow back to the requestor for re-submission
• Request More Information will also send the workflow back to the requestor for re-submission

YAML Example:

legal_signature:
  name: "legal_signature"
  type: "decision"
  approver: "legal_team"
  approval_type: "needs_to_sign"
  on_approve:
    continue_to: "next_step"
  on_reject:
    end_workflow: true

3. needs_to_recommend

Recipients with this role type... can do the following:

• Recommend will move the workflow to the next recipient (if any)
• Not Recommend will also move the workflow to the next recipient (if any)
• Request More Information will send the workflow back to the requestor for re-submission

Note: This role is designed specifically for recipients that do not have authority to decline a request. If you want the recipient to be able to decline the request back to the requestor, use the needs_to_approve role instead.

YAML Example:

finance_review:
  name: "finance_review"
  type: "decision"
  approvers:
    - role: "finance_manager"
      approval_type: "needs_to_recommend"
    - role: "budget_analyst"
      approval_type: "needs_to_recommend"
  # Important: define both paths to keep flow moving
  on_approve:
    continue_to: "next_step"
  on_reject:        # when they choose Not Recommend
    continue_to: "next_step"  # Still proceeds

4. needs_to_acknowledge

Recipients with this role type... can do the following:

• Acknowledge will move the workflow to the next recipient (if any)
• Request More Information will send the workflow back to the requestor for re-submission

YAML Example:

policy_acknowledgment:
  name: "policy_acknowledgment"
  type: "decision"
  approver: "${requestor.supervisor}"
  approval_type: "needs_to_acknowledge"
  on_approve:
    continue_to: "next_step"
  on_reject:
    end_workflow: true

5. needs_to_call_action

Recipients with this role type... can do the following:

• Complete Action will execute the action and move to the next workflow node
• Fail Action will go back to the previous node
• Request More Information will send the workflow back to the requestor for re-submission

Note: This can be an API call or manual task. If it's a manual task, the action creates the task, and once the task is completed, it proceeds. If it's an API call, on success it moves to the next workflow node, if it fails, it goes back to the previous node.

YAML Example:

it_action:
  name: "it_action"
  type: "decision"
  approver: "it_team"
  approval_type: "needs_to_call_action"
  on_approve:
    continue_to: "next_step"
  on_reject:
    continue_to: "next_step"  # Action completed

6. receives_a_copy

Recipients with this role type... receive a copy of the request only. No action is required.

YAML Example:

stakeholder_notification:
  name: "stakeholder_notification"
  type: "decision"
  approvers:
    - role: "requestor"
      approval_type: "receives_a_copy"
    - role: "department_head"
      approval_type: "receives_a_copy"
  on_complete:
    continue_to: "next_step"

Non-blocking Steps

notification_only Step Type

This step type automatically completes without requiring any action:

notify_supervisor:
  name: "notify_supervisor"
  type: "notification_only"
  description: "Supervisor receives notification of request"
  approver: "${requestor.supervisor}"
  on_complete:
    continue_to: "next_step"

receives_a_copy Approval Type

This approval type automatically completes without requiring any action:

stakeholder_copy:
  name: "stakeholder_copy"
  type: "decision"
  approver: "stakeholders"
  approval_type: "receives_a_copy"
  on_complete:
    continue_to: "next_step"

Best Practices

1. Use notification_only for pure FYI notifications that shouldn't block the workflow
2. Use receives_a_copy when you want to send copies but still have a step in the workflow
3. Use needs_to_recommend for advisory roles that shouldn't have veto power
4. Use needs_to_sign for legal or compliance requirements
5. Use needs_to_call_action for steps that require system integration or manual task completion
6. Use needs_to_acknowledge when you need confirmation but don't need full approval

Example Workflow with Mixed Types

workflow:
  # Non-blocking notification
  notify_supervisor:
    type: "notification_only"
    approver: "${requestor.supervisor}"
    on_complete:
      continue_to: "manager_approval"
  
  # Standard approval
  manager_approval:
    type: "decision"
    approver: "${requestor.manager}"
    approval_type: "needs_to_approve"
    on_approve:
      continue_to: "finance_review"
    on_reject:
      end_workflow: true
  
  # Advisory review
  finance_review:
    type: "decision"
    approver: "finance_team"
    approval_type: "needs_to_recommend"
    on_approve:
      continue_to: "legal_signature"
    on_reject:
      continue_to: "legal_signature"  # Proceeds regardless
  
  # Legal signature
  legal_signature:
    type: "decision"
    approver: "legal_team"
    approval_type: "needs_to_sign"
    on_approve:
      continue_to: "completion"
    on_reject:
      end_workflow: true
  
  # Copy to stakeholders
  completion:
    type: "decision"
    approvers:
      - role: "requestor"
        approval_type: "receives_a_copy"
      - role: "department_head"
        approval_type: "receives_a_copy"
    on_complete:
      end_workflow: true