In the world of business automation, we've all felt the pain. A script that worked yesterday suddenly breaks. A complex workflow becomes a tangled mess of dependencies, impossible to debug. A simple change requires a full-scale engineering project. The problem isn't automation itself, but how we build it. We've been building monolithic glass houses instead of assembling sturdy, reliable bricks.
Enter the concept of the atomic action.
The .do platform is built on this powerful idea: business logic should be composed of small, independent, and reusable units. An action.do is the fundamental building block of modern automation—a single, encapsulated task that you can Define, Execute, and Repeat anywhere. It's the foundation of reliable Business-as-Code.
An atomic action is more than just a function; it's a managed, observable, and composable component for your agentic workflows. Think of it as the ultimate Lego brick for automation. But what can you build with these bricks? Let's explore five innovative use cases that showcase the true power of action.do.
import { Do } from '@do-platform/sdk';
// Initialize the .do client with your API key
const-do = new Do(process.env.DO_API_KEY);
// Define a new atomic action to enrich user data
const enrichUserAction = await-do.action.create({
name: 'enrich-user-profile',
description: 'Fetches user data from Clearbit and updates the DB.',
inputs: {
email: 'string',
},
handler: async (inputs) => {
const userData = await clearbit.lookup(inputs.email);
const dbResult = await db.users.update({ email: inputs.email, data: userData });
return { success: true, userId: dbResult.id };
}
});
console.log('Action created:', enrichUserAction.id);
The Challenge: Your sales and marketing teams need rich, up-to-date information on every new lead. Manually looking up data is slow, and hard-coding API calls into every form submission endpoint is brittle and repetitive.
The Atomic Solution: Create a single enrich-lead action.
Why it's better: This one atomic action can be plugged into dozens of agentic workflows. Use it when a new user signs up, when a contact form is submitted, or even in a batch process to clean your existing CRM data. If you decide to switch data providers from Clearbit to a competitor, you only update this one action. Every workflow that uses it is instantly upgraded.
The Challenge: Generating and sending an invoice involves multiple critical steps: creating a PDF, recording the transaction in a database, and emailing the customer. If any step fails (the email service is down), you can end up with an inconsistent state—a recorded invoice that was never sent.
The Atomic Solution: An issue-invoice action.
Why it's better: Because the action is atomic, it either completes all these steps or it fails as a single unit. The .do platform provides observability, so if it fails, you know exactly which step was the problem (e.g., email send failed). You can simply retry the action, confident that you won't create duplicate database records.
The Challenge: Regulations like GDPR and CCPA require strict consent management. You need to ensure that you don't send marketing communications or process data for users who have opted out. Sprinkling if (user.consent) checks across your entire codebase is an error-prone maintenance nightmare.
The Atomic Solution: A verify-data-processing-consent action.
Why it's better: This action becomes a standardized, auditable gatekeeper. Your add-user-to-newsletter workflow's first step is to call this action. Your run-product-analytics workflow does the same. When compliance rules change, you update the logic in this one central action, and your entire system inherits the new rule.
The Challenge: Integrating different SaaS platforms is a constant battle of mismatched data schemas. A "Contact" in HubSpot looks completely different from a "Contact" in Salesforce, which is different again from your internal user model.
The Atomic Solution: A transform-contact-to-salesforce action.
Why it's better: This decouples your core business logic from the specifics of external systems. Your main workflow can operate with a generic "contact" object. When it needs to sync to a destination, it simply calls the appropriate transformation action. Adding a new destination (like a marketing automation tool) is as simple as creating a new transformation action, with no changes to the primary workflow.
The Challenge: Your platform allows user-generated content, but you need to filter out toxic or inappropriate comments. Building and maintaining an AI moderation engine is complex, and relying on manual review doesn't scale.
The Atomic Solution: A moderate-text-content action.
Why it's better: You've encapsulated a highly complex AI task into a simple, reusable workflow step. Any part of your application that accepts user text—comments, reviews, support tickets—can now use this action to get a simple, actionable decision. If you find a better AI model in the future, you swap the API call in this one action, and your entire platform's moderation capability is instantly improved.
These atomic actions are immensely powerful on their own, but their true potential is unlocked when you compose them. On the .do platform, actions are designed to be orchestrated by workflow.do agents. A workflow defines the sequence and logic, chaining together actions to execute complex business processes. This separation of concerns—single tasks in action.do, orchestration in workflow.do—is the key to building automation that is robust, scalable, and a pleasure to maintain.
Ready to move beyond brittle scripts? Start thinking in atomic units.
What is an 'atomic action' on the .do platform?
An atomic action is the smallest, indivisible unit of work in a workflow. It's a self-contained, reusable function that performs a single, specific task, like 'send an invoice' or 'update a CRM record'. This atomicity ensures reliability and simplifies debugging.
How is an action.do different from a serverless function?
While similar, a .do Action is a fully managed, versioned, and observable entity within our platform. It includes built-in input validation, logging, and security, and is designed to be seamlessly composed into larger Agentic Workflows, abstracting away infrastructure concerns.
Can actions call other actions?
No, actions are designed to be atomic. To orchestrate a sequence of actions, you use a .workflow.do agent. This separation of concerns—single tasks in action.do and orchestration in workflow.do—is a core principle for building robust and scalable systems.
What kind of logic can I put inside an action?
An action handler can contain virtually any code: API calls to third-party services, data transformations, database queries, or complex business logic. The key is that the action should focus on successfully completing one well-defined task.