FlowMattic Sub-Workflows and How to Use Them

Hey FlowMattic fans! If you’ve ever found yourself rebuilding the same workflow steps over and over, you’re going to love what I’m about to show you. Sub-Workflows are going to change how you build automations—and I’m going to prove it with real examples you can use today.

Quick note: FlowMattic is a WordPress automation plugin, so all these workflows are built right in your WordPress admin. No external platforms needed!

What This Feature Actually Does

Sub-Workflows let you build reusable workflow components that you can call from other workflows. Instead of copying the same 5 steps into 10 different workflows, you build those steps once and reference them whenever needed.

For anyone with programming experience, a Sub-Workflow works like a function—you pass in parameters, it does some work, and returns results you can use.

But here’s the real magic: When you need to update those steps, you change them in one place and every workflow using them instantly gets the update. No more hunting through dozens of workflows making the same change over and over.

The Three Key Components

Every Sub-Workflow setup uses these three pieces:

1. Start Sub-Workflow (Trigger)

• Used inside the Sub-Workflow only
• Defines what data (parameters) the Sub-Workflow receives
• Always the first step of a Sub-Workflow

2. Call Sub-Workflow (Action)

• Used in parent workflows (the ones calling the Sub-Workflow)
• Activates the Sub-Workflow and passes data to it
• Receives results back when Sub-Workflow completes

3. Return Response (Action)

• Used inside the Sub-Workflow only
• Always the last step of a Sub-Workflow
• Sends processed data back to the parent workflow

Think of it like this: The parent workflow says “Hey Sub-Workflow, here’s some data, do your thing!” The Sub-Workflow processes it and says “Done! Here are your results.”

FlowMattic’s Unique Workflow

FlowMattic has a smart approach to building Sub-Workflows that prevents errors:

1. Create parent workflow first - Add the Call Sub-Workflow action and configure parameters
2. Create Sub-Workflow second - Set trigger to Start Sub-Workflow
3. Click “Capture Response” - Sub-Workflow listens for incoming data
4. Test parent workflow - Sends data to Sub-Workflow
5. Parameters captured automatically - No manual configuration needed!

This “capture response” method ensures the Sub-Workflow knows exactly what parameters to expect. It’s one of FlowMattic’s best features.

Real-World Example 1: Extracting and Formatting Email Data

Let me show you a practical example that’ll make this crystal clear.

The Scenario

You have multiple workflows that process contact information from different sources. Sometimes the email comes in a field with extra text, like:

• Contact us at: [email protected] for more info
• [email protected] (preferred contact)
• Email: [email protected]

You need to extract just the email, convert it to lowercase, and validate the format. You use this logic in 6 different workflows.

The Sub-Workflow Solution

Instead of building the extraction logic 6 times, you build one Sub-Workflow.

Sub-Workflow: “Extract and Validate Email”

Step 1 - Trigger: Start Sub-Workflow

• Input parameter: raw_text (the field containing the email)

Step 2 - Action: Text Formatter → Extract Pattern

• Pattern: Email regex pattern
• Text: {raw_text}
• Result: Extracted email

Step 3 - Action: Text Formatter → Lowercase

• Text: Result from Step 2
• Result: Lowercase email

Step 4 - Action: Text Formatter → Trim Whitespace

• Text: Result from Step 3
• Result: Clean email

Step 5 - Action: Filter (Optional)

• Check if email format is valid
• If not valid, set error status

Step 6 - Action: Return Response

• email: Result from Step 4
• is_valid: true or false based on Filter
• status: success or error

Using It in Parent Workflows

Parent Workflow 1: “Google Forms → MailChimp”

Trigger: New Google Forms response
  ↓
Action: Call Sub-Workflow → "Extract and Validate Email"
  → raw_text: {trigger.contact_field}
  ↓
Filter: Only continue if {call_sub_workflow.is_valid} = true
  ↓
Action: Add subscriber to MailChimp
  → Email: {call_sub_workflow.email}

Parent Workflow 2: “Webform → HubSpot”

Trigger: New webform submission
  ↓
Action: Call Sub-Workflow → "Extract and Validate Email"
  → raw_text: {trigger.email_info}
  ↓
Action: Create or update contact in HubSpot
  → Email: {call_sub_workflow.email}

The Benefit: Six workflows all use the same email extraction logic. Need to change how emails are validated? Update one Sub-Workflow, and all six workflows instantly use the new logic.

Real-World Example 2: Tagging Team Members in Slack

Here’s a real example similar to what many teams need.

The Problem

You get lead notifications in Slack from various sources (website forms, trade shows, partnerships). When a lead comes in from a specific region, you need to tag the sales rep responsible for that region.

You have 4 different lead sources, and each needs this tagging logic.

The Sub-Workflow Solution

Sub-Workflow: “Tag Sales Rep by Region”

Step 1 - Trigger: Start Sub-Workflow

• Input parameters:
  • region (the lead’s region)
  • original_message (the Slack message to reply to)

Step 2 - Action: Router (or Lookup Table)

• Route based on {region}
• East Coast → Set sales_rep_id = “@sarah”
• West Coast → Set sales_rep_id = “@mike”
• Midwest → Set sales_rep_id = “@jennifer”
• South → Set sales_rep_id = “@carlos”
• Default → Set sales_rep_id = “@sales-team”

Step 3 - Action: Text Formatter

• Create tagged message: {sales_rep_id} - New lead in your region!

Step 4 - Action: Return Response

• tagged_message: Result from Step 3
• assigned_rep: The sales rep’s name
• status: success

Parent Workflow: “Website Lead → Slack Notification”

Trigger: New lead from website form
  ↓
Action: Post message to #leads channel
  → Message: "New lead: {trigger.name} from {trigger.region}"
  → Save message timestamp
  ↓
Action: Call Sub-Workflow → "Tag Sales Rep by Region"
  → region: {trigger.region}
  → original_message: {previous_step.message_ts}
  ↓
Action: Post reply in thread
  → Thread: {original_message}
  → Message: {call_sub_workflow.tagged_message}

Other workflows using the same Sub-Workflow:

• “Trade Show Leads → Slack”
• “Partner Referrals → Slack”
• “Cold Outreach Responses → Slack”

All four workflows tag the right sales rep, and if sales territories change, you update the Sub-Workflow once.

Real-World Example 3: Secure Data Access

This is a powerful pattern many teams don’t think about.

The Scenario

Your HR team manages sensitive employee data in BambooHR (salaries, personal info, etc.). Your sales operations team needs to onboard new sales reps, but HR doesn’t want to give them direct access to BambooHR due to the sensitive information it contains.

The Sub-Workflow Solution

HR creates a Sub-Workflow that acts as a secure gateway.

Sub-Workflow: “Get New Hire Info” (Managed by HR team)

Step 1 - Trigger: Start Sub-Workflow

• Input parameter: employee_email

Step 2 - Action: BambooHR → Search Employee

• Search by: {employee_email}

Step 3 - Action: Return Response

• employee_name: {search_result.full_name}
• employee_email: {search_result.email}
• start_date: {search_result.start_date}
• manager_name: {search_result.manager}
• department: {search_result.department}
• Note: Deliberately NOT returning salary, SSN, or other sensitive fields

Sales Ops Team Uses It

Parent Workflow: “New Hire Onboarding” (Built by Sales Ops)

Trigger: New row in "New Hires" Google Sheet
  ↓
Action: Call Sub-Workflow → "Get New Hire Info"
  → employee_email: {trigger.email}
  ↓
Action: Send welcome email via Gmail
  → To: {call_sub_workflow.employee_email}
  → Body: "Welcome {call_sub_workflow.employee_name}! Your manager {call_sub_workflow.manager_name}..."
  ↓
Action: Create Asana onboarding tasks
  → Assignee: {call_sub_workflow.manager_name}
  → Title: "Onboard {call_sub_workflow.employee_name}"
  ↓
Action: Send Slack message to manager
  → User: {call_sub_workflow.manager_name}
  → Message: "New team member {call_sub_workflow.employee_name} starts {call_sub_workflow.start_date}"

The Beauty: Sales Ops can onboard new hires without accessing BambooHR directly. HR maintains control over what data is shared. If HR needs to change what data is available, they update the Sub-Workflow once.

Real-World Example 4: Multi-Source Customer Lookup

Here’s another common scenario that Sub-Workflows solve elegantly.

The Problem

Your customer data is spread across multiple systems:

• CRM (Pipedrive) has contact info
• Billing system (Stripe) has payment history
• Support system (Zendesk) has ticket history

Multiple workflows need to gather all customer info, but you don’t want to build this lookup logic repeatedly.

The Sub-Workflow Solution

Sub-Workflow: “Get Complete Customer Profile”

Step 1 - Trigger: Start Sub-Workflow

• Input parameter: customer_email

Step 2 - Action: Pipedrive → Find Person

• Search by: {customer_email}
• Store: CRM data

Step 3 - Action: Stripe → Find Customer

• Search by: {customer_email}
• Store: Billing data

Step 4 - Action: Zendesk → Search Users

• Search by: {customer_email}
• Store: Support data

Step 5 - Action: Text Formatter → Format

• Combine all found data
• Create summary: “Found in CRM, Stripe, Zendesk” or “Only found in CRM”

Step 6 - Action: Return Response

• customer_name: From CRM
• customer_phone: From CRM
• customer_since: From Stripe
• total_spent: From Stripe
• open_tickets: From Zendesk
• found_in_systems: The summary from Step 5
• status: complete or partial (if not found in all systems)

Multiple Teams Use It

Sales Team Workflow: “Inbound Lead Enrichment”

Trigger: New inbound lead
  ↓
Action: Call Sub-Workflow → "Get Complete Customer Profile"
  ↓
Action: Update lead record with historical data
  ↓
Action: Route to sales rep with context

Support Team Workflow: “VIP Customer Alert”

Trigger: New support ticket
  ↓
Action: Call Sub-Workflow → "Get Complete Customer Profile"
  ↓
Filter: If {call_sub_workflow.total_spent} > $10,000
  ↓
Action: Send VIP alert to support manager

Marketing Team Workflow: “Re-engagement Campaign”

Trigger: Schedule (weekly)
  ↓
Action: Get list of inactive customers
  ↓
Loop: For each customer
  ↓
Action: Call Sub-Workflow → "Get Complete Customer Profile"
  ↓
Action: Personalize email based on their history

Real-World Example 5: API Token Management

If you work with APIs, this one’s a game-changer.

The Scenario

You need to authenticate with an API that requires you to:

1. Request an access token using credentials
2. Use that token in subsequent API calls
3. Tokens expire after 1 hour

You have 12 workflows that all need to interact with this API.

The Sub-Workflow Solution

Sub-Workflow: “Get API Access Token”

Step 1 - Trigger: Start Sub-Workflow

• Input parameters:
  • api_endpoint (in case you have multiple environments)
  • request_reason (for logging purposes)

Step 2 - Action: Webhooks → POST Request

• URL: {api_endpoint}/auth/token
• Body: Your client_id and client_secret
• Store: The response

Step 3 - Action: Text Formatter → Extract

• Extract: access_token from response

Step 4 - Action: Date Formatter

• Get current timestamp
• Add 55 minutes (buffer before actual expiration)
• Store: token expiration time

Step 5 - Action: Return Response

• access_token: The extracted token
• expires_at: Calculated expiration time
• status: success or error

Parent Workflows Use It

Any workflow that needs API access:

Trigger: (Whatever triggers your workflow)
  ↓
Action: Call Sub-Workflow → "Get API Access Token"
  → api_endpoint: "https://api.yourservice.com"
  → request_reason: "Daily sync"
  ↓
Action: Webhooks → GET Request
  → URL: Your API endpoint
  → Headers: Authorization: Bearer {call_sub_workflow.access_token}
  ↓
(Continue with your workflow logic)

The Benefit: If the authentication method changes, you update one Sub-Workflow instead of 12 different workflows. Plus, you can add logging, error handling, and retry logic in one place.

Pro Tips and Patterns

Pattern 1: The Status Checker

Always return a status field in your Sub-Workflows:

Return Response:
  → status: "success" or "error" or "partial"
  → error_message: (if status = error)
  → warning_message: (if status = partial)
  → (your actual data)

Then in parent workflows, add a Filter after the Sub-Workflow call:

Filter: Only continue if {call_sub_workflow.status} = "success"

Pattern 2: The Audit Trail

Return metadata about what your Sub-Workflow did:

Return Response:
  → processed_at: {current_timestamp}
  → records_found: 3
  → records_updated: 2
  → records_failed: 1
  → (your actual data)

Use this in parent workflows for logging and monitoring.

Pattern 3: The Fail-Safe

Handle errors gracefully in your Sub-Workflows:

Step X: Try to fetch data from API
  ↓
Filter: Did it succeed?
  ↓ (Yes)
Path A: Return successful data
  ↓ (No)
Path B: Return Response
  → status: "error"
  → error_message: "API unavailable"
  → fallback_data: (default values)

This keeps parent workflows running even when something goes wrong.

Pattern 4: The Dynamic Router

Use lookup tables or routers in Sub-Workflows:

Sub-Workflow: "Route to Right Team"
Input: ticket_type, priority
  ↓
Router based on ticket_type + priority:
  → Bug + High → Return team: "engineering_leads"
  → Bug + Low → Return team: "engineering"
  → Feature + Any → Return team: "product"
  → Question + High → Return team: "customer_success"
  → Default → Return team: "support"

One Sub-Workflow, dynamic routing logic, used everywhere.

Common Mistakes to Avoid

Mistake 1: Making Sub-Workflows Too Complex

Don’t:
Build one “mega Sub-Workflow” that does 15 different things based on complex conditional logic.

Do:
Build focused Sub-Workflows that do one thing well. Create multiple Sub-Workflows if needed.

Mistake 2: Forgetting the Return Response

Don’t:
Forget to add the Return Response action at the end.

Do:
Always end with Return Response, even if you’re not returning data. Use it to return a simple status.

Mistake 3: Hardcoding Values

Don’t:
Hardcode things like URLs, IDs, or settings in your Sub-Workflow.

Do:
Pass these as parameters so the Sub-Workflow is flexible and reusable.

Mistake 4: Not Testing Edge Cases

Don’t:
Only test with perfect, happy-path data.

Do:
Test with empty values, special characters, extremely long strings, and invalid data to ensure your Sub-Workflow handles everything gracefully.

Mistake 5: Creating Circular References

Don’t:
Have Sub-Workflow A call Sub-Workflow B, which calls Sub-Workflow A.

Do:
Plan your Sub-Workflow architecture to avoid loops. Draw it out if needed.

When Should You Build a Sub-Workflow?

Use this decision framework:

Build a Sub-Workflow if:

• ✅ You use the same steps in 3+ workflows
• ✅ You might use these steps in future workflows
• ✅ The logic is complex and you want to maintain it in one place
• ✅ Multiple team members need to use the same process
• ✅ You need to update the logic frequently

Don’t build a Sub-Workflow if:

• ❌ You only use it in one workflow
• ❌ The logic is just 1-2 simple steps
• ❌ It’s highly specific to one use case and won’t be reused
• ❌ It’s simpler to just copy the steps

Questions or examples to share? Visit FlowMattic Support or join our community forum!

Related Articles:

• Understanding Sub-Workflows in FlowMattic
• Create Reusable Workflow Steps with Sub-Workflows