Workflow Automation Guide

Build Workflows Around How Your Agency Operates

Design HubSpot-style workflows with the flexibility of an n8n-style canvas: trigger from internal events, external events, or APIs, then connect functions, API calls, AI agents, conditions, cases, subprocesses, loops, and approvals.

New workflow Draft
TriggerNew account
AgentQualify lead
IfFit > 70
YES Start pipeline Run subprocess
NO Create task Loop for follow-up

One Builder, Many Operating Motions

Use the same visual workflow model for growth, service, agents, and pipeline execution.

Trigger From Anywhere

Start from internal Prudens events, external webhooks, schedules, inbound messages, or an API request. Call another workflow when a reusable process is needed.

Compose Real Actions

Connect functions, HTTP requests, integrations, AI agents, data updates, notifications, and approvals as visible nodes with inputs and outputs.

Control Every Path

Use if conditions, case branches, loops, stop conditions, subprocesses, and human approvals to keep exceptions and handoffs explicit.

Marketing

Move leads from an event to qualification, enrichment, campaign actions, and follow-up tasks.

Agent Automations

Give agents governed tools, SOPs, and escalation paths while keeping execution observable.

Pipeline Management

Advance records through stages, assign owners, and launch subprocesses when conditions change.

Service Operations

Orchestrate intake, forms, carrier actions, reminders, QA, and completion updates in one flow.

Practical Runbook

Build Your First Workflow

Start with one measurable process, build the happy path, then add exceptions and approvals deliberately.

01

Define the outcome

Write the result in one sentence before opening the builder. For example: “When a qualified lead arrives, create the opportunity, notify the owner, and schedule the next action.”

  • Name the record or event that starts the process.
  • Define what completed means and who owns the outcome.
  • List the information the workflow must have before it can continue.
02

Choose the trigger

Select the event that should create a workflow run. Keep the trigger narrow enough that every run represents real work.

  • Use an internal event when a Prudens record changes or reaches a state.
  • Use an external event or webhook when another system sends the signal.
  • Use an HTTP/API trigger when a service or agent starts the workflow directly.
  • Use a schedule only when the process is time-based rather than event-based.
03

Connect the first actions

Drag actions onto the canvas and connect each output to the next input. Keep the first version linear so it is easy to inspect.

  • Use functions for repeatable transformations or calculations.
  • Use API or HTTP request nodes to read from or write to another system.
  • Use data actions to update records, assign owners, or create tasks.
  • Use an AI agent when the step needs judgment, classification, or tool use.
04

Map inputs and outputs

Every node should declare what it receives and what it makes available to the next node. Use real sample data while mapping fields.

  • Map account, contact, pipeline, and event fields into the node inputs.
  • Pass API responses forward only after checking status and required values.
  • Give outputs stable names so later branches remain readable.
  • Keep sensitive values out of logs and messages unless the next step requires them.
Builder Patterns

Use Control Flow Without Losing Clarity

Branches are useful when they make a decision visible. Keep each path named, bounded, and easy to hand back to the main workflow.

If conditions

Use an If node for a clear yes/no decision such as “is the account complete?” or “is the fit score above the threshold?”

  • Give both outputs a useful label.
  • Define the fallback when the value is missing.
  • Do not hide a material business decision inside a function.

Case branches

Use a Case pattern when one input can lead to several known routes, such as product line, lead source, carrier, or service type.

  • Create an explicit default branch.
  • Keep each case focused on one routing decision.
  • Send unknown values to review instead of silently dropping them.

Loops and retries

Use loops for bounded repeated work, such as checking multiple contacts or carrier markets. Always define when the loop stops.

  • Set a maximum item count or retry count.
  • Store the current item and result for auditability.
  • Route exhausted retries to a person or exception queue.

Subprocesses and reusable workflows

Move repeated logic into a subprocess when multiple workflows need the same behavior. Pass a documented input contract and return a clear result.

  • Use subprocesses for shared tasks such as enrichment, document checks, or notification.
  • Define how the subprocess reports success, failure, and partial completion.
  • Keep the parent workflow responsible for the overall business outcome.

Approvals and stop conditions

Place a human approval before high-impact actions such as sending a recommendation, changing a pipeline stage, or submitting to a carrier.

  • State what the reviewer is approving and show the supporting context.
  • Stop when required data, confidence, authorization, or policy checks fail.
  • Record the approver, decision, timestamp, and reason.
Starter Recipes

Workflows You Can Build First

Use these as starting shapes, then adapt the fields, approvals, and integrations to your operating model.

Marketing qualification

Trigger: form submission or inbound event.

Flow: enrich contact, run an AI qualification step, branch by fit, create or update the pipeline record, then notify the owner.

Control: send incomplete or low-confidence records to a review queue.

Agent-led service automation

Trigger: portal request, email, SMS, or phone activity.

Flow: classify intent, attach the relevant SOP, collect missing information, call approved tools, and send a confirmation.

Control: escalate when the SOP, confidence threshold, or required data says the agent must stop.

Pipeline progression

Trigger: record stage change or API request.

Flow: validate required fields, create tasks, call external systems, start a subprocess, and move the record to the next stage.

Control: require approval for exceptions and record why a stage did or did not advance.

Before You Publish

Test, Activate, and Improve

A workflow is ready when the happy path works, the exception paths are visible, and someone owns the outcome.

Test with controlled data

  • Run a complete happy-path example with representative account and pipeline data.
  • Test missing fields, failed API responses, duplicate events, and low-confidence agent results.
  • Confirm that loops terminate and subprocesses return to the expected parent state.
  • Check that notifications, tasks, and record updates happen only once.

Publish with ownership

  • Name the workflow by outcome, not by an internal experiment name.
  • Document the trigger, inputs, integrations, approval points, and stop conditions.
  • Assign an owner and define who reviews failed or paused runs.
  • Start with a limited audience or pipeline segment before expanding.

Monitor the first two weeks

Completion rate Failed and paused runs Approval time Retry and rework volume Time to outcome User feedback