Your First Agentic Workflow: A Step-by-Step Guide to Automating Customer Onboarding

Manual customer onboarding is a tightrope walk. One wrong step—a missed email, a delayed account setup, a forgotten notification—and the entire new customer experience can falter. These processes are often brittle, hard to scale, and prone to human error. But what if you could define your business processes as code, creating resilient, autonomous systems that execute tasks with precision?

This is the promise of agentic workflows, powered by the .do platform. Today, we'll guide you through automating a customer onboarding process step-by-step. The secret lies in a simple yet powerful concept: atomic actions.

An atomic action is the fundamental building block of automation on .do. It's a single, indivisible task that either succeeds completely or fails cleanly, ensuring your systems never get stuck in a weird, partial state. By composing these reliable blocks, you can build complex and robust agentic workflows.

BUILDING BLOCKS FOR AUTOMATION

From Chaos to Code: Why Atomic Actions are Crucial

Before we build, let's understand the "why." Imagine your current onboarding looks like this:

1. A new user signs up.
2. A support person manually creates their record in the CRM.
3. They then switch to your billing system to set up an account.
4. Finally, they copy-paste a template into an email and send a welcome message.

What happens if they get distracted after step 2? You have a user in your CRM but not in your billing system. This inconsistency creates downstream problems.

Agentic workflows solve this by automating the entire sequence. The "atomic" nature of action.do provides the transactional integrity needed for reliability. Think of it like a bank transfer: you can't just debit one account without crediting another. Both operations must succeed, or the entire transaction fails. Similarly, an atomic action like setup-billing-account won't leave you with a half-created customer record.

Step 1: Deconstruct Your Workflow into Atomic Actions

The first step in Business-as-Code is to think like an architect. Let's break our customer onboarding process down into distinct, single-responsibility tasks. Each one will become a reusable, API-callable action.do.

For our onboarding workflow, we need four atomic actions:

• create-user-in-db: A single action that takes user details and creates a new record in your primary database.
• setup-billing-account: An action that communicates with an external API (like Stripe or Braintree) to create a customer billing profile.
• send-welcome-email: An action that uses a mailing service API (like SendGrid or AWS SES) to dispatch a templated welcome email.
• notify-sales-on-slack: An action that posts a message to a specific Slack channel to let the team know about the new customer.

By encapsulating each task, we create a library of reliable business capabilities that can be called from anywhere.

Step 2: Execute an Action with the .do SDK

Now for the fun part: let's bring an action to life. The .do platform provides powerful SDKs to make API integration seamless. Here’s how you would execute your send-welcome-email action using our TypeScript SDK.

import { Do } from '@do-platform/sdk';

// Initialize the .do client with your API key
const client = new Do({ apiKey: 'YOUR_API_KEY' });

// Execute a predefined atomic action by name
async function sendWelcomeEmail(userId: string) {
  try {
    const result = await client.action.execute({
      name: 'send-welcome-email',
      params: {
        recipientId: userId,
        template: 'new-user-welcome-v1'
      }
    });
    console.log('Action Executed Successfully:', result.id);
    return result;
  } catch (error) {
    console.error('Action Failed:', error);
  }
}

// Run the action for a new user
sendWelcomeEmail('user_12345abc');

Let's break down this code:

1. Initialization: We import and initialize the .do client with our secure API key.
2. Execution: We call client.action.execute(), which is the core function for running any atomic action.
3. name: We specify the globally unique name of the action we want to run: 'send-welcome-email'.
4. params: We pass a structured object containing all the data the action needs to perform its task. This makes the action incredibly flexible and reusable.
5. Error Handling: The try...catch block is vital. If the action fails for any reason (e.g., the email service API is down), the SDK will throw an error. Because the action is atomic, you can be confident that no partial work was done—no email was half-sent. You can then log the error, trigger an alert, or queue a retry.

Step 3: Compose Actions into a Service Workflow

Executing a single action is powerful, but the real magic happens when you orchestrate them into a complete business outcome. On the .do platform, this is called a Service (service.do).

A service is a higher-level workflow that defines the sequence and logic for calling multiple atomic actions. While the full definition of a service.do is a topic for another day, you can imagine it conceptually as:

// Conceptual definition of an onboarding service
service 'customer-onboarding-workflow' {
  input: {
    userName,
    userEmail
  }

  // Chain actions together to form the workflow
  1. Execute action 'create-user-in-db' with params(name: userName, email: userEmail)
  2. Execute action 'setup-billing-account' with params(email: userEmail)
  3. Execute action 'send-welcome-email' with params(recipientEmail: userEmail)
  4. Execute action 'notify-sales-on-slack' with params(customerName: userName)
}

This service chains our atomic building blocks into a fully automated, end-to-end process. The platform manages the state, execution, and error handling between each step, providing a level of resilience that's nearly impossible to achieve with scattered scripts and manual intervention.

Frequently Asked Questions (FAQ)

What is an 'atomic action' in the context of .do?

An atomic action is the smallest, indivisible unit of work within a workflow. It represents a single, specific task—like sending an email or updating a database record—that either completes successfully or fails entirely, ensuring system reliability and preventing partial states.

How do actions differ from services?

An action (action.do) is a single, granular operation. A service (service.do) is a higher-level business capability composed of one or more actions orchestrated into a workflow. Actions are the building blocks; services are the valuable outcomes.

Can I create my own custom actions?

Yes. The .do platform empowers you to define your own custom actions using Business-as-Code. You can encapsulate any business logic, external API call, or script into a reusable, versioned, and callable action for your agentic workflows.

How are actions invoked?

Actions are invoked programmatically through the .do API or our language-specific SDKs. You simply call the action by its unique name and provide the necessary parameters, allowing for seamless integration into any application or system.

What happens when an action fails?

Because actions are atomic, a failure is handled cleanly without leaving your system in an inconsistent state. The platform provides detailed error logging and allows you to configure automated retries, notifications, or alternative compensatory actions.

Start Building Today

You've just taken your first step into the world of agentic workflows. By breaking down complex processes into simple, atomic actions, you can build automation that is not only powerful but also predictable and reliable. The customer onboarding workflow is just the beginning. Imagine applying this to order fulfillment, data processing, infrastructure provisioning, and more.

Ready to replace fragile scripts with resilient, code-defined business processes?

Explore the .do Platform and start building your first atomic action today.