Customer onboarding is a critical first impression. It's also a surprisingly complex process, often involving multiple systems, notifications, and setup tasks. When done manually or with brittle scripts, it's a process ripe for errors: a welcome email isn't sent, a user's workspace isn't provisioned correctly, or a new lead is never added to the CRM. These small failures create a poor customer experience and lead to internal chaos.
What if you could define this entire business process as code? Not just a single script, but a robust, auditable, and fault-tolerant system built from simple, reusable components. This is the promise of agentic workflows, and in this case study, we'll walk through how to build a flawless customer onboarding process using the .do platform.
Let's break down a typical customer onboarding flow. When a new user signs up on your website, a chain of events needs to occur:
A simple script could chain these API calls together, but what happens when the email service API is temporarily down? Or the Slack notification fails? The entire process halts in an unknown state. The user might exist in your database but never get an email, and your sales team is left in the dark. This is where thinking in "atomic actions" changes the game.
The core principle behind .do is breaking down large processes into their smallest, indivisible parts. We call these atomic actions. An atomic action is a single operation that either succeeds completely or fails completely, leaving no partial state.
For our onboarding scenario, we don't have one big "onboard user" script. Instead, we define five independent, single-purpose actions:
Each of these is a small, manageable, and testable unit of work. This approach provides three immediate benefits: Reliability, Auditing, and Reusability.
At the heart of the .do platform is the action.do API, which provides a reliable, auditable, and idempotent way to perform these tasks. Idempotency is key—it ensures that running the same action with the same inputs multiple times has the exact same effect as running it once. You can't accidentally send a customer five welcome emails.
Here’s how simple it is to execute one of our defined actions:
import { Do } from '@do-sdk/core';
// Initialize the .do client with your API key
const a = new Do(process.env.DO_API_KEY);
// Execute the 'send-welcome-email' atomic action with parameters
const { result, error } = await a.action.execute({
name: 'send-welcome-email',
params: {
userId: 'usr_12345',
template: 'new-user-welcome-v2'
}
});
if (error) {
console.error('Action failed:', error);
} else {
console.log('Action Succeeded:', result);
}
This is the fundamental building block. But how do we connect them to form our full onboarding process?
While action.do represents the individual steps, workflow.do is the conductor that orchestrates them. A workflow is a sequence or graph of these atomic actions that defines your end-to-end business process.
Our customer onboarding workflow could be visualized like this:
graph TD
A[User Signs Up Trigger] --> B(Start Onboarding Workflow);
B --> C[run: create-user-record];
C --> D[run: provision-workspace];
D --> E[run: send-welcome-email];
D --> F[run: create-crm-contact];
F --> G[run: post-slack-message];
This isn't just a diagram; it's a programmable and executable definition. With .do, you define this logic as code. The platform then takes on the responsibility of task execution.
Let's revisit our failure scenario: the email service is down.
Once the email service is back online, you can resume the workflow from the exact point of failure. The platform re-runs the send-welcome-email action. Because it's idempotent, there's no risk of duplicates. Once it succeeds, the workflow continues to the CRM and Slack actions as if nothing ever happened.
This is the power of the "Execute. Audit. Repeat." model. Every action is a durable, auditable transaction, making your systems incredibly resilient.
By breaking down a complex business process into a workflow of atomic actions, we’ve transformed a brittle script into a robust, scalable, and transparent system.
This is more than just workflow automation; it's a true Business-as-Code approach. Your core operational logic is now version-controlled, testable, and as dependable as your application code.
What constitutes an 'atomic action'?
An atomic action is a single, indivisible operation that either completes successfully or fails entirely, leaving no partial state. Examples include sending a single email, making one API call, or writing a single record to a database.
Why is idempotency important for actions?
Idempotency ensures that executing the same action multiple times with the same parameters has the same effect as executing it once. This is crucial for building reliable systems that can recover from failures without causing unintended side effects, like sending duplicate invoices.
How does action.do relate to a workflow.do?
action.do represents the individual steps or building blocks. A workflow.do is a sequence or graph of these actions orchestrated to achieve a larger business outcome. You compose workflows from one or more atomic actions.
Can I define my own custom actions?
Yes. The .do platform allows you to define your own custom actions as functions or microservices, which can then be invoked via the action.do API. This turns your existing business logic into reusable, auditable components.