When to Trigger a Workflow vs Keep It in the Master

Use Cases
1

Hello, I’m Abdul, and I work on the sales team at Process Street. I was recently talking to a customer who was asking me about this - when I should keep it in the master, and I decided to create a quick community post for anybody else who may have run into the same issue.

The quick answer

Trigger a separate workflow when the activity has its own lifecycle, owner, or SLA, when it is reused across multiple processes, or when it needs an independent audit trail. Keep it in the master workflow when steps are tightly coupled, short in duration, and owned by the same team.

Decision framework

Create a triggered workflow if

  • Ownership differs. Another team or vendor is responsible, with separate approvals or SLAs.

  • The work recurs in many places. Think KYC checks, device provisioning, or legal review.

  • It runs on a different clock. Lead time or frequency does not match the master.

  • It is long running or asynchronous. Work waits on external systems or third parties.

  • It needs its own audit trail. Regulators may ask for standalone proof.

  • It has complex branching. Logic and exceptions would bloat the master.

  • It is sensitive. Access rules differ from the master process.

  • It will be improved independently. Version at its own pace.

Keep steps in the master workflow if

  • Steps are tightly coupled. Output of one is input to the next.

  • One owner and one SLA. Same team, same timeline.

  • It is short and deterministic. Few steps, little variance.

  • Context matters. The performer needs upstream and downstream context.

  • Evidence belongs with the main record. Auditors expect one file.

Design patterns

Reusable subroutine

Build once as a standalone workflow, then trigger from any master that needs it. Examples include background checks, device provisioning, OFAC or KYC checks, identity verification, and account creation.

Handoff to specialists

Trigger to the owning team. Pass only required data. Track status and SLA. Attach evidence back to the master on completion. Examples include legal review, contract signature, risk assessment, and quality inspection.

Exception path

Trigger only when a threshold is crossed. Examples include high risk vendor score, failed QA sample, or overdue task.

Parallel fan out

Start several child workflows at once and let them run independently. Wait for completion, then aggregate results.

Compliance trail

Use discrete workflows to produce shareable audit trails for vendor risk, CAPA, policy attestations, and internal audit findings.

Trigger design checklist

  • Name the interface. Define data sent and status required back.

  • Define the contract. Inputs, owners, service levels, completion rules.

  • Map the handoff. What fires the trigger, who is notified, what happens on failure.

  • Close the loop. Write back key fields, attach artifacts, and update the parent run.

  • Secure it. Scope permissions so teams see only what they need.

  • Measure it. Track cycle time, first time right, and reopen rate. Review quarterly.

Examples

New hire onboarding

Master covers hiring manager tasks and day one. Trigger background check, device provisioning, payroll setup, and benefits enrollment as separate workflows. Each has its own owner and SLA. The master waits for all to complete before finalizing.

Vendor onboarding

Master collects core vendor details and initiates approvals. Trigger risk assessment, contract review, and security questionnaire as separate workflows. Each produces a shareable audit trail, then writes back risk score, contract status, and acknowledgments to the parent run.

Change management in regulated environments

Master manages impact analysis and scheduling. Trigger training and attestation, system validation, and CAPA follow up as discrete workflows. Each can be audited independently while the master tracks the full change record.

Incident response

Master handles triage and containment. Trigger root cause analysis and corrective actions as standalone workflows. Close the loop by publishing lessons learned and updating related SOPs.

How to implement in Process Street

  1. Model the master in Ops. Mark clear handoff points and required data.

  2. Build the subroutine as its own workflow with the right forms, approvals, and SLAs.

  3. Connect with a trigger using run links, automations, or integrations with mapped fields.

  4. Synchronize status. Use automations or an API step to update the parent run.

  5. Attach proof. On completion, push files, approvals, and key values back to the master.

  6. Govern the policy in Docs. Link the policy to both workflows and version changes.

Quality guardrails

  • Keep names consistent across master and child workflows.

  • Keep scope tight. One child workflow per purpose.

  • Keep feedback flowing with a short close survey.

Red flags

  • Too many conditions or nested approvals in the master.

  • Teams skip steps or manage work inside channels.

  • Cycle time varies wildly for the same process.

  • Auditors ask for separate proof for a subset of steps.

  • Small changes require edits to many templates.

Summary

Split when ownership, clock, or compliance needs diverge. Keep together when work is short, coupled, and owned by one team. Design the handshake, secure the data, and close the loop for faster execution, lower risk, and cleaner proof.

2 Likes