Drafts Automation: Turn Text Into Action

What is Drafts Automation and Why It Matters

Drafts automation refers to the practice of using the Drafts application—a text capture and processing tool available on iOS and macOS—to automatically transform, route, and act upon text input without manual intervention. Rather than typing text into Drafts and then manually copying it elsewhere or performing repetitive edits, automation allows you to define workflows that execute predefined actions immediately after text entry or on demand.

The core value of Drafts automation lies in eliminating friction from text-based tasks. Most knowledge work involves capturing ideas, reformatting information, and sending it to other applications. Without automation, this becomes a series of discrete steps: open an app, type or paste content, switch to another app, format the text, and send it to its destination. Drafts automation collapses these steps into a single action, reducing cognitive load and the time spent on mechanical tasks.

The Problem It Solves

Consider a common scenario: you capture a list of tasks throughout the day in various places—email, messages, voice notes—and need to consolidate them into your task management system. Without automation, you would manually copy each item, switch apps, paste it, format it correctly, and assign it metadata like due dates or projects. This is tedious, error-prone, and interrupts your actual work.

Drafts automation addresses this by allowing you to write once and distribute everywhere. A single text entry can simultaneously create a calendar event, send a message, update a database, and log information to a note-taking system—all triggered by a single action. This is particularly valuable for people who work with text constantly: writers, developers, researchers, project managers, and anyone who needs to move information between tools.

How Drafts Automation Works: The Architecture

Drafts automation operates through a layered system of actions, scripts, and integrations. Understanding this architecture is essential to using Drafts effectively.

Actions are the primary unit of automation in Drafts. An action is a predefined workflow that takes the text in your draft and performs one or more operations on it. Actions can be simple—like converting text to uppercase—or complex, involving multiple steps, conditional logic, and external API calls. When you trigger an action, Drafts executes its instructions in sequence.

Scripts

Integrations

The typical flow works like this: you enter or paste text into a draft, then trigger an action. The action processes the text according to its definition—which may involve running a script, formatting the content, and sending it to one or more destinations. The result is that your text has been captured, processed, and distributed without you needing to manually perform any of the intermediate steps.

Types of Automation in Drafts

Drafts automation takes several forms, each suited to different use cases.

Text Processing Automation manipulates the content of your draft. This includes formatting (converting to markdown, HTML, or plain text), parsing (extracting specific information from structured text), and transformation (replacing patterns, sorting lines, or reorganizing content). A writer might use text processing automation to convert a rough outline into a formatted article structure. A developer might use it to convert a list of variable names into code comments.

Distribution Automation sends your text to other applications and services. This is where Drafts acts as a hub, receiving text from one place and sending it to many others. You might write a single note that automatically creates a task, sends a message to a team member, and logs an entry to a database. Distribution automation is valuable because it ensures consistency—the same text is sent everywhere, with no risk of transcription errors—and it saves time by eliminating manual copying and pasting.

Conditional Automation uses logic to decide what happens based on the content or metadata of your draft. For example, if your draft contains a specific tag, it might route to one destination; if it contains a different tag, it routes elsewhere. If the draft is longer than a certain number of words, it might format differently. Conditional automation allows you to create flexible workflows that adapt to different situations without requiring separate actions for each scenario.

Scheduled Automation executes actions at specific times rather than immediately. While Drafts itself doesn't natively schedule actions for future execution, you can use integrations with services like Zapier or IFTTT to trigger Drafts actions on a schedule, or you can use Drafts' ability to create reminders that can execute actions when triggered.

Why This Matters in Practice

The significance of Drafts automation becomes clear when you consider the volume of small, repetitive text tasks that accumulate throughout a workday. A project manager might need to create 15 tasks from email messages. A researcher might need to format citations in a specific way. A support team member might need to log customer issues to multiple systems simultaneously. A writer might need to send drafts to multiple reviewers with consistent formatting.

Without automation, each of these tasks requires multiple steps and app switches. With automation, each becomes a single action. Across dozens of daily tasks, this compounds into hours of reclaimed time and mental energy. More importantly, automation reduces errors. When a process is automated, it executes consistently every time, eliminating the mistakes that occur when humans manually perform repetitive steps.

Drafts automation also enables new workflows that would be impractical to do manually. For instance, you could create an action that takes a voice note, transcribes it, extracts any mentions of people or projects, creates tasks for each mention, and logs the original note to an archive—all in seconds. This kind of sophisticated workflow is only feasible through automation.

The Distinction Between Drafts and Other Automation Tools

Drafts automation is distinct from broader automation platforms like Zapier, IFTTT, or Apple Shortcuts, though it can integrate with them. Those tools are designed to connect any two services without requiring text as the central medium. Drafts automation is specifically built around text as the primary input and output. You capture text in Drafts, and automation processes and distributes that text.

This text-centric design makes Drafts particularly powerful for workflows that involve writing, editing, or reformatting. It's less useful for automations that don't involve text—for example, automatically turning on lights or sending a notification without text content. Conversely, Drafts automation excels at tasks where text is central, because the tool is purpose-built for that use case.

Additionally, Drafts automation is more accessible to non-programmers than many alternatives. While you can write JavaScript if you want advanced capabilities, Drafts provides a visual action builder that allows you to create many common automations without writing code. This democratizes automation, making it available to people who don't have programming experience.

Core Components of a Drafts Automation

Every automation in Drafts consists of several components, even if some are implicit or use defaults.

Input is the text you're working with. This can come from typing directly into Drafts, pasting content, or using Drafts' capture features (like voice input or sharing from other apps). The input is the raw material that automation processes.

Processing is where the automation works on the text. This might involve running a script, applying formatting rules, extracting specific information, or validating the content. Processing is optional—some actions skip directly to output—but most automations include at least some processing step.

Routing determines where the processed text goes. It might go to another app, be sent via email or message, be written to a file, be posted to a web service, or be stored in a database. Many automations route to multiple destinations simultaneously. Routing decisions can be static (always send to the same place) or dynamic (decide based on the content or metadata).

Output is the result of the automation. This might be a task created in a task manager, a message sent to a colleague, a file saved to cloud storage, or an entry logged to a database. The output is what you see as the result of triggering the automation.

Feedback is optional but valuable. Good automations provide feedback to confirm that they executed successfully. This might be a notification, a message displayed in Drafts, or a confirmation that the action completed. Without feedback, you might not know if an automation worked or failed.

The Broader Context: Why Drafts Automation Is Growing

Drafts automation has become increasingly important as work has become more fragmented across multiple tools. Most people now use five to ten different applications daily: email, messaging, task management, note-taking, calendar, and specialized tools for their specific work. Getting information from one tool to another requires manual effort. Drafts automation addresses this fragmentation by providing a central hub where text can be captured and intelligently distributed.

The rise of mobile-first work has also increased the relevance of Drafts automation. On mobile devices, app switching is more cumbersome than on desktop, making automation more valuable. Drafts is available on iOS, making it practical for mobile users who need to capture and process text on the go.

Additionally, the growing emphasis on personal productivity systems—like Getting Things Done, Zettelkasten, and similar methodologies—has highlighted the importance of frictionless capture and processing. Drafts automation enables these systems by removing the friction from the capture-to-action pipeline.

Building Your Drafts Automation Strategy: Step-by-Step Implementation

Effective automation in Drafts requires more than installing actions—it demands a deliberate approach to identifying which tasks deserve automation, designing workflows that actually save time, and integrating them into your existing habits. This section walks through the complete process of planning, building, testing, and refining automation that works.

Step 1: Audit Your Current Workflow and Identify Automation Candidates

Before writing a single action or connecting a single service, map the work you actually do. Open Drafts and spend a week noting every time you perform a repetitive task: copying text to a specific format, sending the same information to multiple places, reformatting captured content, or moving drafts between workspaces based on tags or content patterns.

The best automation candidates share these characteristics:

• You perform them multiple times per week
• They follow the same sequence every time, with only minor variations in the content itself
• They involve moving information between Drafts and other apps or services
• They require formatting, filtering, or reorganizing text before the final destination
• They consume five minutes or more per occurrence

Tasks that happen once monthly, require significant human judgment at each step, or already take thirty seconds are poor automation candidates. Automating them creates maintenance burden without meaningful time savings.

Document these candidates in a simple spreadsheet or list. Note the exact sequence of steps, which information must transfer between systems, where decisions happen, and which parts could be standardized. This becomes your automation roadmap.

Step 2: Define the Input, Processing, and Output for Each Workflow

Every automation follows this pattern: something triggers it, something happens inside Drafts, and something leaves Drafts. Clarity about each stage prevents building actions that seem logical but fail in practice.

Input stage: How does content enter the automation? Is it a new draft you've already captured? Is it selected text? Is it triggered by a specific tag or workspace? Is it initiated manually through an action menu, or should it run automatically when certain conditions are met? Different inputs require different technical approaches, and choosing the wrong one creates friction.

Processing stage: What happens to the content once it's in Drafts? Common processing includes extracting specific information using regular expressions, reformatting dates or lists, combining multiple drafts, filtering content based on keywords, or applying consistent styling. This is where Drafts' text manipulation features, scripting capabilities, and conditional logic become essential. Be specific about what the content should look like after processing.

Output stage: Where does the processed content go? Common destinations include email, messaging apps, note-taking systems, project management tools, cloud storage, or other apps on your device. Some workflows have multiple outputs—the same processed text might go to email and to a note-taking system simultaneously. Understand what format each destination expects and whether Drafts can deliver it directly or needs an intermediary service.

Document this for each workflow in a three-column format: Input → Processing → Output. This clarity prevents building actions that technically work but don't solve your actual problem.

Step 3: Choose Your Technical Approach: Built-In Actions, Scripts, or External Services

Drafts provides multiple ways to build automation, each suited to different complexity levels and integration needs.

Built-in action steps are the fastest starting point. Drafts includes pre-built steps for common tasks: appending or prepending text, replacing content, creating new drafts, opening URLs, sending to clipboard, and basic integrations with mail, messages, and other services. If your workflow consists entirely of these operations, you can build a complete action without touching code. The trade-off is limited flexibility—you're constrained to what the built-in steps provide.

JavaScript scripting through Drafts' script step offers far greater control. You can write conditions that check the content of your draft, extract specific information, perform calculations, or manipulate text in ways the built-in steps don't support. Scripts can also access Drafts' object model directly, allowing you to create, modify, or delete drafts programmatically, work with tags and workspaces, or access device information. Learning to write basic scripts opens possibilities that built-in steps alone cannot reach. However, this requires some programming knowledge and introduces the possibility of errors that break your workflow.

External services like Zapier, IFTTT, or Make (formerly Integromat) act as intermediaries between Drafts and hundreds of other applications. When Drafts alone cannot reach a service you need, or when you need complex conditional logic that spans multiple apps, these services bridge the gap. The cost is latency—actions take longer to execute—and complexity in managing another platform's interface. Use external services when Drafts' direct integrations fall short, not as your first choice.

For most workflows, start with built-in actions. Move to scripting when built-in steps cannot express what you need. Use external services only when the destination app or required logic genuinely demands it.

Step 4: Build Your First Action—Start Minimal

Create a new action in Drafts and add only the essential steps to solve your specific problem. Resist the urge to build a comprehensive solution that handles every edge case on the first attempt.

If your workflow is "capture a meeting note and send it to my project management tool," your first version might be: capture text → add a timestamp → send via email to a specific address. This works. It's not sophisticated, but it solves the problem.

Test this minimal version repeatedly with real content from your actual work. Does it produce output in the format you need? Does it reach the right destination? Does it actually save you time compared to doing the task manually? Only after confirming these basics should you add refinements like conditional logic, multiple outputs, or complex text processing.

Many automation projects fail because they attempt too much complexity too early. A simple action that works consistently is infinitely more valuable than an elaborate action that you abandon because it's unreliable or too difficult to maintain.

Step 5: Test with Real Data and Edge Cases

Run your action against actual content from your work, not just clean examples. If you're automating something that processes meeting notes, test it with notes that contain special characters, multiple paragraphs, embedded links, or unusual formatting. If it processes lists, test it with lists of different lengths and structures.

Identify the edge cases that might break your automation: What happens if the input is empty? What if it contains characters your action doesn't expect? What if the destination service is temporarily unavailable? What if the user runs the action twice on the same draft by accident?

Build safeguards for the most likely problems. Add a step that confirms the action is about to run before executing irreversible operations. Include error handling in scripts that might fail. Test the action multiple times and across different content types before relying on it for important work.

Step 6: Integrate the Action Into Your Actual Workflow

An action that exists in Drafts but you never use provides no value. Ensure the action is accessible at the moment you need it.

If the action should run manually, add it to your action menu or create a keyboard shortcut. If it should run automatically based on conditions, set up a scheduled action or a tag-based trigger. If it's part of a larger workflow, consider whether it should be a separate action you run consciously or a step within a larger action that handles multiple related tasks.

The best accessibility method depends on how often you use it and whether you think of it as a distinct task or part of a larger process. An action you use dozens of times daily deserves a keyboard shortcut. An action you use weekly might live in your action menu. An action that runs automatically based on content patterns needs no manual access at all.

Step 7: Monitor, Refine, and Expand

After using your automation for two weeks, assess whether it's actually solving the problem you identified. Is it faster than doing the task manually? Does it produce reliable results? Do you use it consistently, or do you sometimes bypass it because it's easier to do the task without automation?

If the action is working well, consider whether similar tasks could use the same approach. If you've automated sending meeting notes to one system, could the same action send them to multiple systems? If you've automated formatting one type of content, could the same logic apply to other content types?

If the action isn't working, diagnose why. Is the problem technical—does the action have bugs or limitations? Is it practical—does the action require more steps than doing the task manually? Is it habitual—do you simply forget to use it? Different problems require different solutions. A technical problem might need scripting fixes. A practical problem might mean the automation isn't actually saving time and should be abandoned. A habitual problem might be solved by making the action more visible or accessible.

Common Mistakes in Drafts Automation and How to Avoid Them

Building Automation for Tasks That Don't Repeat

The most common mistake is automating something you do once or twice. Automation has overhead—you must design it, build it, test it, and maintain it. If a task happens rarely, the time investment in automation exceeds the time you'll save. Automation becomes valuable only when the same task repeats frequently enough that cumulative time savings justify the initial investment.

Before building an action, estimate how many times per month you'll use it. If the answer is fewer than four times, reconsider whether automation is worth the effort. If it's more than four times, automation likely makes sense.

Creating Actions So Complex They Break Easily

Ambitious automation often fails because it tries to handle too many scenarios, uses fragile text parsing that breaks with minor variations in input, or relies on external services that don't always respond reliably. A ten-step action with conditional branches that tries to handle every possible variation is harder to debug when something goes wrong and harder to modify when your needs change.

Build actions that solve the common case reliably. If edge cases exist, handle them explicitly rather than trying to make one action work for everything. It's better to have three simple, reliable actions than one complex action that sometimes fails.

Forgetting That Automation Requires Maintenance

When an app you use updates its API, or when a service you rely on changes its format, your automation may break. Actions that worked perfectly for months can suddenly stop working without warning. This isn't a failure of automation itself—it's a consequence of depending on external systems that change.

Plan for maintenance. Check your automations periodically to ensure they're still working. When something breaks, fix it quickly rather than letting it sit unused. Consider which automations are critical to your workflow and which are nice-to-have; focus maintenance effort on the critical ones.

Using External Services When Drafts Can Do It Alone

Zapier, IFTTT, and similar services are powerful, but they add latency and complexity. An action that runs entirely within Drafts executes instantly. An action that must send data to an external service, wait for processing, and potentially send data back takes longer and depends on internet connectivity and the reliability of the external service.

Exhaust Drafts' native capabilities first. Only use external services when Drafts genuinely cannot reach the destination or perform the required logic. This keeps your automations fast and reliable.

Not Testing With Real Data

An action that works perfectly with clean, simple test data may fail spectacularly with real data from your actual work. Real data contains special characters, unusual formatting, unexpected edge cases, and variations you didn't anticipate when building the action.

Always test automations with real content from your actual workflow. Run the action multiple times with different types of input. Deliberately try to break it. Only after it survives real-world testing should you rely on it for important work.

Building Actions Without Understanding the Destination

Before building an action that sends content somewhere, understand exactly what format that destination expects and what happens if the format is wrong. An email action might work fine, but if you're sending to a system with specific formatting requirements, the email might arrive unformatted or in the wrong structure.

Read the documentation for the destination app or service. Test sending content to it manually first. Understand what information it requires, what format it expects, and what happens if something goes wrong. Only then build the automation.

Making Automation Inaccessible

An action that's technically perfect but buried three menus deep will be used rarely. Accessibility matters as much as functionality. If you've built an action you use daily, it should have a keyboard shortcut. If it's something you use weekly, it should be prominent in your action menu. If you're unsure whether you'll use it, make it easy to access so you can test whether it actually fits your workflow.

Building Sustainable Automation: A Practical Framework

Sustainable automation follows a simple principle: each action should solve one specific problem reliably, with minimal maintenance, and be accessible when you need it. Actions that violate this principle—that try to do too much, break frequently, or are hard to find—eventually fall into disuse.

Stage	Key Question	Common Mistake	How to Avoid It
Planning	Does this task repeat frequently enough to justify automation?	Automating one-off tasks	Only automate tasks that happen at least four times monthly
Design	What exactly enters, gets processed, and exits?	Unclear input/output requirements	Document the complete flow before building
Building	What's the simplest way to solve this?	Over-engineering with unnecessary complexity	Start with built-in steps; add scripting only if needed
Testing	Does it work with real data?	Testing only with clean examples	Test extensively with actual content from your work
Integration	Can you easily access it when needed?	Building great actions nobody uses	Make frequently-used actions easily accessible
Maintenance	Is it still working?	Ignoring broken automations	Check periodically and fix issues quickly

Follow this framework and your automations will remain useful, reliable, and maintainable over time. Skip steps or rush through them, and you'll build actions that seem like good ideas but never quite work the way you hoped.

Tools, Workflows, and Verification Methods

Native Drafts Automation Components

Drafts provides several built-in mechanisms for automation that operate independently of external integrations. The Action system forms the core: actions are reusable sequences of steps that process text, modify drafts, or trigger external services. Actions can be triggered manually from the action list, assigned to keyboard shortcuts, or executed automatically when drafts are created or modified. The action editor accepts both visual step configuration and scripting in JavaScript, allowing users to build anything from simple text replacements to complex conditional workflows.

Scripting in Drafts uses a JavaScript engine with a comprehensive API for accessing draft content, tags, metadata, and system functions. The script object provides methods to read and write draft text, access the clipboard, create new drafts, and manage draft metadata. The HTTP object enables direct API calls to external services without requiring a separate integration layer. Developers can write custom functions, loop through text, perform conditional logic, and handle errors within a single action step.

Templates and template tags provide a simpler alternative to scripting for users who prefer configuration over code. Template tags use double-bracket syntax to insert dynamic content: [[draft]] inserts the full draft text, [[date]] inserts the current date in configurable formats, [[line|1]] retrieves a specific line, and [[selection]] inserts highlighted text. Templates can be nested and combined to generate complex output without writing JavaScript.

External Service Integration Patterns

Drafts connects to external services through several integration methods, each suited to different use cases. URL schemes allow Drafts to send data to other applications on the same device using standardized URL protocols. For example, a Drafts action can construct a URL that opens Apple Reminders with a pre-filled task, or opens Apple Notes with draft content already populated. URL schemes are limited to passing text and simple parameters but work reliably across iOS, iPadOS, and macOS.

HTTP requests represent the most flexible integration approach. Actions can POST draft content to web services, retrieve data from APIs, and process responses. A common pattern involves sending draft text to a webhook service that logs entries to a database, sends notifications, or triggers downstream workflows. The HTTP step supports authentication headers, custom request bodies, and response parsing through JavaScript, enabling integration with services that lack native Drafts support.

Webhook receivers like Zapier, Make (formerly Integromat), and IFTTT accept HTTP POST requests from Drafts and trigger actions in hundreds of connected services. This approach decouples Drafts from specific integrations: a single HTTP request to a webhook can simultaneously log to a spreadsheet, send a message, create a calendar event, and update a project management system. The webhook service handles authentication and routing, reducing complexity in the Drafts action itself.

Some services provide native Drafts actions through action groups or direct integration. These pre-built actions handle authentication, formatting, and service-specific requirements, allowing users to activate integrations without scripting. Native actions are typically maintained by the service provider or the Drafts community and are distributed through the Drafts action directory.

Manual Workflows Supported by Automation

Drafts automation accelerates several common manual workflows. The capture-and-process pattern involves creating a draft, triggering an action that extracts specific data, and routing that data to appropriate destinations. A user might capture a voice memo, run an action that transcribes it (if Drafts has access to transcription), extracts key phrases, and sends structured data to a task manager. Without automation, each step would require manual copying and switching between applications.

The templated output workflow uses actions to generate formatted content from minimal input. A user types a few keywords, runs an action that expands those keywords into a full email template, meeting agenda, or project brief, and then edits the result. This reduces repetitive typing and ensures consistency across similar documents.

The multi-destination workflow sends a single draft to multiple services simultaneously. A user writes a note once and runs an action that posts it to a blog, shares it to social media, sends it via email, and archives it to a note-taking service. Without automation, the user would manually copy the text and repeat the posting process for each service.

The conditional routing workflow uses logic to send drafts to different destinations based on their content or metadata. A user might tag a draft with a project name, and an action automatically routes it to the corresponding project management system, calendar, or archive location. This eliminates manual sorting and reduces the chance of misfiled information.

Verification and Testing Methods

Testing Drafts automation requires checking both the action execution and the downstream result. Start by creating a test draft with known content and running the action in isolation. Observe whether the action completes without errors and whether any expected output appears in Drafts itself (such as modified draft text, new drafts created, or console messages).

For actions that interact with external services, verify the result by checking the destination service directly. If an action sends data to a spreadsheet, open the spreadsheet and confirm the new row appears with correct values. If an action creates a calendar event, check the calendar application. If an action sends an HTTP request, use a service like RequestBin or Webhook.cool to capture and inspect the actual request being sent, including headers and body content.

Enable the action's console output to see detailed execution logs. In the action editor, toggle the "Show console" option and run the action again. The console displays variable values, HTTP response codes, error messages, and any text printed by JavaScript console.log() statements. This visibility is essential for debugging complex actions with multiple steps or conditional logic.

Test with edge cases: run the action on empty drafts, drafts with special characters, very long text, and text containing line breaks. Verify that the action handles these cases gracefully without crashing or producing corrupted output. If the action uses regular expressions or text parsing, test with variations of expected input formats.

For actions involving timing or scheduled execution, verify that they trigger at the expected moments. Create a test draft and observe whether automatic actions fire when the draft is created or modified. Check system logs or the destination service to confirm the action ran at the scheduled time.

FAQ

What is the difference between an action and a script in Drafts?

An action is a reusable sequence of steps that can include multiple components: text manipulation steps, script steps, HTTP requests, and conditional logic. A script is a single step within an action that contains JavaScript code. Most actions include at least one script step, but simple actions might use only template tags or built-in steps without any scripting. Think of actions as workflows and scripts as the code that powers individual steps within those workflows.

Can Drafts automation work offline?

Yes, but with limitations. Actions that manipulate text, create drafts, modify tags, and use templates work entirely offline. Actions that require HTTP requests to external services, or that send data via URL schemes to services that require internet connectivity, will fail or queue for later execution depending on how the action is configured. Some actions can be set to queue requests and retry when connectivity is restored.

How do I automate a task that happens on a schedule rather than when I create a draft?

Drafts itself does not support scheduled execution of actions at specific times. However, you can use external services like Zapier, Make, or IFTTT to trigger actions on a schedule. These services can send an HTTP request to a Drafts webhook at specified intervals, which can then trigger an action in Drafts. Alternatively, use iOS Shortcuts to run Drafts actions on a schedule through the Shortcuts automation feature, which supports time-based triggers.

What happens if an action fails partway through execution?

By default, if any step in an action fails, the action stops and displays an error message. The draft remains unchanged unless earlier steps already modified it. You can configure error handling in scripts using try-catch blocks to catch errors and decide whether to continue, skip a step, or display a custom message. Some actions include conditional steps that check for errors and take alternate paths based on the result.

Can I use Drafts automation to send data to services that don't have official integrations?

Yes. If the service has a public API or accepts HTTP POST requests, you can construct an HTTP step in a Drafts action to send data directly. You will need to understand the service's API documentation, including the correct endpoint URL, required headers, and request body format. This requires either scripting knowledge or willingness to learn basic HTTP request construction. Many community-created actions already do this for popular services.

How do I share an action I've created with other Drafts users?

Export the action from the action editor using the share icon, which generates a URL or a text representation of the action. You can share this URL directly, or post it to the Drafts community forums, Reddit, or other platforms. Other users can import the action by opening the URL on their device or pasting the action definition into Drafts. If the action uses scripts or credentials specific to your account, document which values need to be customized.

Can Drafts automation modify files on my device or in cloud storage?

Drafts can write files to its own storage and to iCloud Drive through native actions. For other cloud services like Google Drive, Dropbox, or OneDrive, you must use integrations via HTTP requests or webhook services. Drafts does not have direct file system access on iOS due to platform restrictions, so file operations are limited to services that provide APIs or to files stored in locations accessible through the Files app.

What's the best way to debug an action that isn't working as expected?

Start by enabling console output in the action editor and running the action on a test draft. Read the console messages carefully for error messages or unexpected variable values. Add console.log() statements to your script to print intermediate values. If the action involves HTTP requests, capture the actual request using a webhook inspection service to verify that the correct data is being sent. Test each step of the action independently if possible. Check the destination service to confirm whether data actually arrived, which helps determine whether the problem is in Drafts or in the downstream service.

Can I create an action that processes multiple drafts at once?

Not directly through a single action execution. However, you can create an action that iterates through all drafts in your library using the Drafts API, processes each one, and performs an operation on each. This requires scripting. Alternatively, you can create a simpler action and apply it to multiple drafts by selecting them in the draft list and running the action, which applies it to each selected draft sequentially.

How do I prevent an action from accidentally modifying my draft content?

Review the action's steps carefully before running it on important drafts. Test new actions on throwaway test drafts first. If an action modifies draft text, you can undo the change immediately using the undo function. Some actions include a "preview" mode that shows what will happen without actually making changes. You can also create a backup action that exports your drafts before running experimental automations. Always check the action documentation or source code to understand what modifications it will make.