Workflow Rules & Triggers

This page describes how organizations can configure workflow rules and triggers in Axvero to automate business processes and application status changes.

Overview

Workflow rules and triggers allow organizations to define custom automation logic for their application lifecycle. When a specific event (trigger) occurs, Axvero executes the configured rule, which may include actions such as notifications, API calls, or data updates.

Key Concepts

Trigger: An event or condition that starts the workflow automation (e.g., status change, new application submission).
Rule: The logic that defines what actions should be taken when a trigger occurs. Rules can include conditions and multiple actions.
Action: The operation performed when a rule is triggered (e.g., send notification, call workflow API, update record).
Condition: Optional criteria that must be met for the rule to execute (e.g., application type, priority).

Default Workflow Rules

When an organization is created in Axvero, a set of default workflow rules is automatically configured to cover common application lifecycle events and actions. These defaults ensure basic automation and compliance out of the box.

Organizations can review, reconfigure, or extend these rules in the admin interface:

Reconfigure: Modify triggers, conditions, or actions of default rules to better fit organizational needs.
Add New Rules: Create additional rules for custom automation scenarios.

Configuration

Organizations can configure workflow rules and triggers using the Axvero admin interface:

Review Default Rules: Start by reviewing the automatically configured rules.
Select Trigger: Choose the event that will start the workflow (e.g., status changes, application creation).
Define Conditions: Optionally specify criteria for when the rule should apply.
Configure Actions: Select one or more actions to execute when the rule is triggered.
Save & Test: Review the rule and test it to ensure correct behavior.

Rule Configuration Format

Axvero recommends using YAML for workflow rule configuration due to its readability and ease of use for technical users. Rules can be defined in a single YAML file, which is easy to edit and maintain.

Each rule should specify when actions are triggered using the phase field:

before: Actions run before the status change is applied.
after: Actions run after the status change is applied.

Example: Simple Workflow Rule

YAML
JSON

- trigger:
    from: Underwriting
    to: Compliance Review
  phase: after
  condition:
    applicationType: Premium
  actions:
    - notify_team
    - call_workflow_api:
        endpoint: /status-change

[
  {
    "trigger": {
      "from": "Underwriting",
      "to": "Compliance Review"
    },
    "phase": "after",
    "condition": {
      "applicationType": "Premium"
    },
    "actions": [
      "notify_team",
      {
        "call_workflow_api": {
          "endpoint": "/status-change"
        }
      }
    ]
  }
]

Example: Multiple Rules in One File

YAML
JSON

- trigger:
    from: Application Submitted
    to: Initial Screening
  phase: after
  actions:
    - notify_team

- trigger:
    from: Initial Screening
    to: Risk Evaluation
  phase: before
  condition:
    priority: High
  actions:
    - notify_manager
    - call_workflow_api:
        endpoint: /risk-evaluation

- trigger:
    from: Decision
    to: Approved
  phase: after
  actions:
    - notify_applicant
    - call_workflow_api:
        endpoint: /approval

[
  {
    "trigger": {
      "from": "Application Submitted",
      "to": "Initial Screening"
    },
    "phase": "after",
    "actions": ["notify_team"]
  },
  {
    "trigger": {
      "from": "Initial Screening",
      "to": "Risk Evaluation"
    },
    "phase": "before",
    "condition": {"priority": "High"},
    "actions": [
      "notify_manager",
      {"call_workflow_api": {"endpoint": "/risk-evaluation"}}
    ]
  },
  {
    "trigger": {
      "from": "Decision",
      "to": "Approved"
    },
    "phase": "after",
    "actions": [
      "notify_applicant",
      {"call_workflow_api": {"endpoint": "/approval"}}
    ]
  }
]

For more details on YAML syntax, see YAML documentation.

Example Workflow Rule

A rule might be configured as follows:

Trigger: Status changes from "Underwriting" to "Compliance Review"
Condition: Application type is "Premium"
Actions: Notify team, call workflow API endpoint /status-change

Workflow API Call Data

To keep integration lightweight and secure, Axvero sends only minimal context to external workflow API endpoints when a rule is triggered. This typically includes:

applicationId
organizationId
trigger details (from, to, phase)
timestamp

External services can then call back Axvero's API to fetch any additional details they require for processing. This approach ensures only necessary data is sent initially, and full details are fetched on demand.

Workflow Rule Trigger Sequence (Diagram)

The following sequence diagram illustrates how Axvero triggers workflow rules and interacts with external services:

This diagram shows that Axvero only sends minimal context to the external service, which can then fetch additional data as needed. This keeps integration simple and secure.

Best Practices

Keep rules simple and focused on maintainability.
Use conditions to avoid unnecessary actions.
Test rules thoroughly before enabling in production.
Document each rule for clarity and compliance.
Design external workflow APIs to fetch required data from Axvero when needed.

Overview​

Key Concepts​

Default Workflow Rules​

Configuration​

Rule Configuration Format​

Example: Simple Workflow Rule​

Example: Multiple Rules in One File​

Example Workflow Rule​

Workflow API Call Data​

Workflow Rule Trigger Sequence (Diagram)​

Best Practices​

Related Pages​