Workflows

There is a gap between your systems

Your campaigns guide contacts through your communication. That covers most of everyday work, but not all of it.

Alongside it sit the tasks that have little to do with a single contact: an order from the shop needs processing. A list from an outside system needs fetching every night. Something happening in another tool should trigger something in Caymland M4. Someone should get a message when a payment arrives.

Until now there were two ways to do that: a developer, or a second automation tool that your data then also runs through.

Workflows are the third way. They are part of Caymland M4, and your data stays there.

Campaigns guide people, workflows guide data

The two are separate on purpose:

• A campaign decides who gets which message and when, who moves into which stage, who collects points. It thinks in contacts.
• A workflow fetches, checks, transforms and hands over data. It thinks in operations.

That an automation running in the background cannot accidentally reach into your customer communication is not a coincidence. It is built that way.

What starts a workflow

• By hand, when you run it.
• On a schedule, every night or every Monday morning.
• Through a webhook, when another system gets in touch. The workflow can answer it as well.
• On an event in Caymland M4, for example when a contact is saved.
• From another workflow, as a sub-workflow.

What happens in between

You assemble the sequence in the builder and see at every point which data arrives where. The building blocks cover what a data flow needs:

• Fetch and hand over. Read data from another system, write data to it, query states.
• Check and branch. Conditions, distribution across several paths, and bringing them back together afterwards.
• Reshape. Set and rename fields, filter, sort, limit, split, aggregate and remove duplicates, until the data has the shape the next system expects.
• Control timing. Wait until something is ready, or continue a sequence at a fixed time.
• Reuse. Build recurring parts once and use them everywhere as a sub-workflow.

Any system offering an interface can be connected. Ready-made connections exist for common services, and that selection keeps growing.

When something goes wrong

An automation that fails quietly is worse than none. So you decide, step by step, what should happen on an error: retry, continue despite the error, or stop the run.

Every run is recorded: when it started, how long it took, what went in and out at each step, with the real data. A run can be repeated instead of reconstructing the error.

Credentials do not live in the workflow

Credentials for outside systems are managed separately. Anyone editing a workflow does not see them. And anyone editing a credential does not overwrite the stored secret by accident, as long as they do not explicitly replace it.

What this looks like day to day

The nightly list. Every night the previous day's bookings are fetched from the specialist system, reduced to the relevant ones and updated as contacts.

The incoming signal. Another system reports a signed contract by webhook. The workflow checks it, assigns it and sets the contact's stage.

The notification. When an operation passes a threshold, a message goes to the responsible channel before anyone has to ask.

The reconciliation. Two systems hold the same customers. A workflow compares them regularly and reports where they drift apart.