RMT Engineering Logo
Workflows, triggers and journeys

Workflow Automation

A conversation ends and the work it created begins. The CRM update. The ticket nobody raised. The refund sitting on someone's desk waiting for a sign-off. A workflow does that work while the conversation is still warm, and it stops to ask a person when the decision is above its authority.

  • 50+ triggers with filter conditions
  • Runs pause for human approval
  • Retries, then a dead-letter queue
We reply within one business day. No newsletter.
100+ Workflow nodes
50+ Trigger types
68 CRM workflow nodes
Step 5 of 7 Runs paused for a person

Automate everything around the conversation

A run starts from something that actually happened. A call completed, an escalation raised, a CSAT score submitted. Then it does the work: calls your API, updates the CRM record, raises the ticket, waits for a sign-off, sends the follow-up. Calls that fail are retried with backoff, and whatever still fails lands in a dead-letter queue you can open and replay, rather than disappearing quietly into a log nobody reads.

The conversation is half the work

In most centres the second half gets done from memory at the end of a shift, when the conversation is hours cold and a good deal of the detail has gone with it. Some of it never gets done at all. The ticket somebody meant to raise tomorrow morning is the one the customer rings about tonight, and by then nobody can find the note. A workflow does that same work at the moment the event fires. It leaves a record of what it did and why.

How it fits together

The path a conversation takes through Workflow Automation

A workflow run from trigger through filter conditions, nodes and branching to human approval, retries and the dead-letter queue Trigger webhook · email · schedule Filter conditions per trigger type Nodes HTTP · SQL · CRM · ITSM · send Branch if/else · switch · AI decision Call failed? retry with backoff Dead-letter queue nothing disappears Human approval the run pauses, holding state Completed and logged step by step Signed outbound webhooks carry the result on, with HMAC verification and delivery logs.

The accent path is the happy one. The grey path is what happens when a call fails — retried with backoff, then dead-lettered where someone can see it.

By the numbers

Few Facts - at a glance

  • 100+

    nodes across logic, data, communication, chat, CRM, ITSM, ERP and connectors

  • 50+

    trigger types, each with its own filter conditions

  • 68

    CRM workflow nodes for Salesforce, HubSpot, Zoho and Pipedrive

The process

How It Works

The four stages, end to end

A run is not a black box. Four things happen between the event and the receipt, and each one is recorded separately: what started the run, which nodes it called, which branch it took, how it ended. At two in the morning, that is the difference between reading a failure back and reconstructing it.

  1. The trigger fires

    Something happens. A call completes, a webhook arrives, an email lands, 09:00 comes round. Filter conditions on the trigger decide whether this particular event is worth a run, so the workflow does not wake up for every closed conversation in the queue.

  2. Nodes do the work

    The run walks its nodes in order. An HTTP or GraphQL call with authentication and retries. A SQL query. A CRM record update, a ticket in your ITSM tool, an SMS to the customer. Each node records what it sent and what came back, so nobody has to guess later which system swallowed the payload.

  3. It branches, or it waits

    If/else, switch and AI decision nodes choose the path. Loops walk a collection. Delays hold the run for a day, or for the sixty days a renewal journey needs. A step above the workflow's authority stops and asks a person, and it keeps its state while it waits.

  4. The receipt

    Every step is logged: the payload, the branch taken, the response, who approved it and when. Failed calls retry with backoff. What still fails is dead-lettered where you can see it, and signed outbound webhooks carry the result on to whatever comes next.

Features

Every capability you need in one module

1. Triggers for everything

Most contact-centre automation is a person copying a value from one screen into another. A trigger with a filter condition removes that job entirely, and it starts from what actually happened in the conversation rather than from a nightly export.

Start a workflow from an inbound webhook, an email arriving, a calendar event, a schedule or a manual run. Or from the conversation itself: lead created, call completed, conversation closed, escalation raised, CSAT submitted, budget threshold crossed. That is 50+ trigger types, each carrying its own filter conditions, so a single trigger can be narrowed down to voice and WhatsApp conversations in the collections queue above a value you set. None of it waits for a batch job.

  • Inbound webhook
  • An email landing in a shared mailbox
  • Calendar event
  • A schedule, down to the hour
  • Conversation events: closed, escalated, CSAT submitted
  • Manual run, for the one-off

See how CSAT and quality scores are produced

Illustrative interface. Events and conditions are sample data.

2. Nodes that reach your systems

HTTP and GraphQL calls with authentication and retries. SQL queries. CRM nodes for Salesforce, HubSpot, Zoho and Pipedrive, 68 of them. Ticket creation across 11 ITSM tools. Email, SMS and WhatsApp sends. SAP S/4HANA and NetSuite for the ERP side. And a JavaScript node for the case none of them cover, and there always is one.

  • HTTP and GraphQL with auth and retries
  • SQL queries
  • 68 CRM nodes
  • 11 ITSM tools
  • Email, SMS and WhatsApp sends
  • SAP S/4HANA and NetSuite
  • JavaScript node

Tell us which system you need connected

3. Branch, loop, wait, approve

The difference between automation you can leave running and automation you have to watch is whether it can pause. A run that reaches a decision above its authority waits for a person. It holds its state and picks up exactly where it stopped.

If/else and switch branching, filters and parallel execution, loops over collections, delays and waits. And human approval steps that hold a run until somebody signs off, keeping the whole state of the run while it sits there, so nothing has to be re-entered when the answer finally comes back on Monday morning. AI decision nodes let a model pick the branch when the rule is fuzzier than a condition can express. Most workflow tools can branch. Far fewer can hold a run open for two days without losing what was in it.

  • If/else, switch, filters, parallel execution
  • Loops over collections
  • Delays and waits, up to the sixty days a renewal journey needs
  • Human approval steps, plus AI decision nodes for when the rule is fuzzy

See the guardrails an AI decision node has to clear

Illustrative interface. The run, the customer and the amount are sample data.

4. Customer journeys

A journey is a workflow with a sense of timing. It runs over days rather than seconds, splits its audience by whatever you actually know about those people, and picks the hour each of them is most likely to read the message.

Multi-step journeys, segmented by audience, with send-time optimisation and journey-level A/B testing. Onboarding sequences, renewal nudges, win-back campaigns and post-purchase follow-up, each of them running on whichever channel that particular customer actually answers on rather than the one your marketing team happens to prefer. The A/B test compares two whole sequences rather than two subject lines, which is where most of the learning turns out to be.

  • Audience segmentation
  • Send-time optimisation, per person rather than per campaign
  • A/B testing at journey level, not subject-line level
  • Onboarding, renewal, win-back, post-purchase

See the channels a journey can run on

5. Connect to your automation stack

A platform that insists on owning every automation is a platform you will fight. OptiML publishes its triggers and actions into the tools your team already uses, and it signs everything it sends outward so the receiving system can prove where the payload came from.

Native triggers and actions in Zapier, Make, Workato, n8n, Pabbly, Pipedream, IFTTT and Tray. Signed outbound webhooks with HMAC verification, automatic retries and a dead-letter queue. If your operations team already automates somewhere else, none of that has to be torn down and rebuilt here. No migration project.

  • Native triggers and actions in eight iPaaS tools
  • HMAC-signed outbound webhooks
  • Delivery logs
  • Automatic retries, then a dead-letter queue you can replay
  • REST API, SDKs and a Terraform provider
iPaaS platforms

Native triggers and actions in Zapier, Make, Workato, n8n, Pabbly, Pipedream, IFTTT and Tray. Eight platforms. Whatever your operations team already maintains in them keeps working, and nobody has to rebuild it here first.

Signed webhooks

Outbound webhooks are HMAC-signed, retried automatically, and every delivery is logged. What still cannot be delivered goes to a dead-letter queue you can inspect and replay, rather than being dropped quietly.

Request the webhook reference

Your own code

When neither the palette nor an iPaaS covers it, a JavaScript node and an expression evaluator run inside the workflow. The REST API, the SDKs and the Terraform provider let the whole thing be built and versioned from your own repository instead.

Talk to us about API and Terraform access

Zapier Make Workato n8n Pabbly Pipedream IFTTT Tray

Use Cases

Where Workflow Automation delivers value

Human approval steps

A refund above the limit stops and waits

A consumer lender (illustrative)

Scenario

A conversation closes with a refund agreed. The workflow reads the amount. Anything over the desk limit goes to a human approval step instead of straight to the payments API, and the run holds at step five of seven with the customer, the invoice and the amount on one card. A team leader approves, declines or asks a question.

Outcome

Nobody has to sit and watch the automation to be sure it will not pay out something it should not. The run knows where its authority ends. It resumes at step six the moment someone answers.

Conversation-event triggers with ITSM nodes

The ticket exists before the agent hangs up

A broadband provider (illustrative)

Scenario

The call-completed trigger is filtered down to fault calls in the technical queue. The workflow reads the diagnosis out of the conversation summary, opens a ticket through the ITSM node, writes the ticket number back onto the CRM record and texts it to the customer. All of that inside a couple of seconds of the call ending. The agent types nothing.

Outcome

Wrap-up stops being the place tickets go missing. The customer has a reference number before the phone is back in their pocket.

Segmented journeys with send-time optimisation

A renewal nudge that arrives when it is read

A subscription software team (illustrative)

Scenario

A renewal journey runs across the sixty days before a contract ends. Not one email at day fifty-nine. The audience is split by plan and by how that customer has replied before, send-time optimisation picks the hour for each person, and the A/B test runs at journey level, comparing two whole sequences rather than two subject lines.

Outcome

The follow-up lands on the channel each customer actually answers on. And because the comparison is between two journeys rather than two subject lines, what you learn from it is worth reusing next quarter.

At a glance

Specification

The numbers and limits, without the sales copy

Specification for Workflow Automation
Specification Detail
Nodes 100+ across logic, data, communication, chat, CRM, ITSM, ERP and connectors
Triggers 50+ — webhook email calendar schedule conversation event manual
Control flow If/else switch filter parallel loop delay human approval AI decision
Custom logic JavaScript node, expression evaluator
CRM nodes 68, covering Salesforce, HubSpot, Zoho and Pipedrive
ITSM Ticket creation across 11 tools
ERP SAP S/4HANA, NetSuite
iPaaS Zapier Make Workato n8n Pabbly Pipedream IFTTT Tray
Webhooks HMAC-signed, retried, with delivery logs and dead-letter queue
Journeys Multi-step segmented send-time optimised A/B testable
Run history Step-by-step log of trigger, branch, payload, response, approver and duration
Failure handling Retry with backoff, then a dead-letter queue you can inspect and replay
Build and version Visual canvas, plus REST API, SDKs and a Terraform provider
FAQ

Questions,
answered

What teams ask us before they roll out Workflow Automation — how it works, what it needs from your side, and what happens when it gets something wrong

Still not sure?

Talk to a specialist and get a straight answer.

Ask our team

An OptiML workflow can start from an inbound webhook, an email arriving, a calendar event, a schedule, a manual run, or a conversation event such as lead created, call completed, conversation closed, escalation raised, CSAT submitted or budget threshold crossed. Workflow Automation ships 50+ trigger types. Each one carries its own filter conditions, so a trigger can be narrowed down to voice and WhatsApp conversations in the collections queue above a value you set.

Workflow Automation reaches your CRM and ticketing systems directly, through nodes rather than through an overnight export. HTTP and GraphQL calls with authentication and retries, SQL queries, 68 CRM nodes covering Salesforce, HubSpot, Zoho and Pipedrive, ticket creation across 11 ITSM tools, SAP S/4HANA and NetSuite ERP nodes, and email, SMS and WhatsApp sends. None of that goes through a nightly file or a staging table somebody has to remember to clear. Where nothing in the palette fits, a JavaScript node and an expression evaluator run inside the workflow itself.

No. Workflow Automation publishes native triggers and actions into Zapier, Make, Workato, n8n, Pabbly, Pipedream, IFTTT and Tray, so what your operations team already maintains keeps running. Outbound webhooks from OptiML are HMAC-signed and logged, which lets the receiving system verify that a payload really came from your tenant. Most teams end up running both, and that is fine.

Workflow Automation retries a failed call with backoff. What still will not go through lands in a dead-letter queue you can inspect and replay, rather than being dropped quietly. Every run is logged step by step: the trigger, the branch taken, each payload and response, the approver and the timing. A bad run is something you open and follow, not something you reconstruct from memory a week later.

Only what the nodes you built send, to the systems you connected them to. The OptiML tenant is hosted in the region you choose at deployment, and every outbound delivery is signed and logged, so there is a record of each payload that left. Approval steps mean the decisions you would rather not automate never go out without a person attached to them.

Connected solutions

Where Workflow Automation is used

The Solutions pages that lean on this module, and what it looks like once it is configured for a particular floor, job title or job to be done.

20 solutions built on this module
Talk to a specialist

Bring the process nobody wants to do

Pick one thing your team still does by hand after a call. The record nobody updated. The refund that has been sitting on a sign-off since Tuesday. We will build it as a workflow on the call, fire a test event through it while you watch, and leave you the run history it produced so you can show somebody else afterwards.

  • 30 minutes
  • A workflow built on your own process
  • No slide deck unless you want one

Book your slot

Leave your email and our team will come back to you within one business day.

or reach us directly

Your details stay private. We never share them.

This website uses cookies.

Cookies are small text files that allow us to create the best browsing experience for you on our site. By continuing to use this website or clicking "Accept & Close", you are agreeing to our use of cookies. To understand how we use cookies or how to manage them, please see our cookies policy.

Ask OptiML

Powered by RMT Engineering