In the world of software development, automation is king. We write scripts, set up cron jobs, and build microservices to handle everything from user onboarding to data processing. But as these systems grow, they often become a tangled web of dependencies—monolithic scripts that are brittle, difficult to debug, and nearly impossible to reuse. What if there was a better way?
Enter the principle of atomicity. By breaking down complex processes into their smallest, indivisible components, we can build automation that is robust, scalable, and easy to maintain. This is the core philosophy behind action.do: representing a single, executable step as code.
This post is your guide to migrating your existing automation to the action.do model. We'll explore how to deconstruct your current workflows and refactor them into a library of simple, powerful, and reusable atomic actions.
At its heart, an action.do is the fundamental building block of automation. It performs one specific task, like sending an email or updating a database record. This "single responsibility principle" is the key to unlocking several powerful advantages over traditional automation scripts.
This approach transforms your operational processes into "Business as Code," allowing you to version, test, and deploy business logic with the same rigor you apply to your application code.
Migrating doesn't mean starting from scratch. It's a strategic process of refactoring. Here’s how to get started.
Look at your existing automation—your cron jobs, CI/CD pipeline scripts, or internal backend services. Your first task is to identify the individual, discrete steps within them.
Consider a typical "new user signup" script. It might look something like this:
Each one of these numbered items is a perfect candidate for an action.do.
Once you've identified a task, encapsulate its logic inside an action.do. The .do SDK makes this straightforward. You define an id, a description, and an execute function that contains the core logic.
Let's take the "send a welcome email" task. This is how you would define it as an action:
import { action } from '@do-sdk/core';
// Define an action to send a welcome email
const sendWelcomeEmail = action.create({
id: 'send-welcome-email',
description: 'Sends a welcome email to a new user.',
execute: async ({ email, name }) => {
// Your email sending logic via an external API
// e.g., using SendGrid, Postmark, or AWS SES
console.log(`Sending welcome email to ${name} at ${email}...`);
// The action returns a structured result
return { success: true, messageId: 'xyz-123' };
}
});
// To test or execute the action directly
const result = await sendWelcomeEmail.execute({
email: 'jane.doe@example.com',
name: 'Jane Doe'
});
Notice how the action is stateless. It receives all the data it needs (email, name) through its input parameters, performs its task, and returns a result.
Repeat Step 2 for each of the core tasks you identified. Create actions for validate-user-input, create-database-record, and post-slack-notification. You are now building a powerful library of reusable components that represent your core business operations.
With a library of atomic actions at your disposal, the final step is to orchestrate them. This is where workflow.do comes in. A workflow defines the sequence and logic, chaining your actions together to accomplish a larger goal.
You can now rebuild the original "new user signup" process not as a fragile script, but as a resilient workflow.do that calls each action.do in sequence, passing data from one step to the next. This composition is how you scale from single tasks to delivering valuable Services-as-Software.
Q: What is an 'atomic action' in the context of .do?
A: An atomic action is the smallest, indivisible unit of work in a workflow. It performs a single, specific task, like 'send an email' or 'update a database record', ensuring that operations are reliable, testable, and easy to debug.
Q: How does an action.do differ from a workflow.do?
A: An action.do represents a single step, while a workflow.do orchestrates multiple actions to achieve a larger business outcome. You build powerful workflows by composing a series of simple actions.
Q: Can I create my own custom actions?
A: Yes. The .do platform is designed for extensibility. You can define your own custom actions using our SDK, encapsulating your specific business logic and integrating any third-party API to make them available in any workflow.
Q: Are actions stateful?
A: No, actions are stateless by design. They receive input, perform their task, and produce output without retaining memory of previous executions. State management is handled at the workflow level, ensuring actions are reusable and predictable.
Migrating your existing automation to action.do is not about a massive, all-at-once rewrite. It's a shift in mindset and a strategic refactoring process. Start small. Pick one script. Identify its core components and transform them into clean, testable, and reusable atomic actions.
By embracing this modular approach, you'll lay the foundation for more reliable, scalable, and maintainable agentic workflows, turning your business logic into a true competitive advantage.