MMS Vegas

Tag: production

  • Make Data Stores: How They Work, When to Use Them, and the Limits That Will Surprise You

    Last updated: June 2026

    Table of contents

    1. What a data store actually is
    2. When to use one — and when not to
    3. Creating a data store and defining your structure
    4. The five operations you will use
    5. Reading all records: the pagination trap
    6. Using data stores across multiple scenarios
    7. The real limits: size, records, and what happens when you hit them
    8. Quick reference
    9. Frequently asked questions

    Make’s data store is a simple key-value database that lives inside your Make account. You create it, define its columns, and then any scenario you own can read from or write to it — no external database required.

    That sounds modest, and it is. But for the specific problems it solves — remembering what ran last time, deduplicating records across scenario runs, passing state between two unrelated scenarios — it’s the right tool, and the alternatives (Google Sheets as a makeshift database, a paid Airtable base, an external database connection) all cost more friction than the job warrants. The catch is that Make’s documentation explains the mechanics without explaining when and why, and there are several limits that will surprise you if you discover them in production. This guide covers both.

    What a data store actually is

    A data store is a lightweight table — rows and columns — that Make hosts for you. Each data store belongs to your Make team and persists between scenario runs. Unlike a scenario’s internal variables (which reset every run) or the data that flows through a module’s output (which disappears the moment the scenario finishes), a data store keeps its values until you explicitly change or delete them.

    You define the structure: a name for the store, and a list of columns with types (text, number, boolean, date, array, object). One column can be designated the key — Make uses this as the unique identifier for each row. If you don’t designate a key, Make generates a numeric ID automatically.

    That’s the whole model. It’s not a relational database. There are no joins, no foreign keys, no indexes beyond the key column. Think of it as a persistent spreadsheet that your scenarios can read and write to mid-run.

    When to use one — and when not to

    Data stores are the right answer for a short list of problems.

    Deduplication. Your trigger fires for every new record in a source, but some records have already been processed. Store the unique ID of each processed record in a data store, then check for it at the start of each run. If it’s there, skip. If it isn’t, process and write it. This is the most common real-world use of data stores, and it works cleanly.

    Cross-scenario state. Two scenarios need to share a value — a counter, a flag, a last-run timestamp — but they have no other connection. Writing to a shared data store is the cleanest solution. One scenario writes the value; the other reads it. No external system needed.

    Simple queues. You can write records to a data store in one scenario and process them in another, clearing each record once it’s handled. This works well for low-volume queues where strict ordering and delivery guarantees don’t matter.

    When not to use one. Data stores are not the right tool for large datasets, reporting, or anything that requires search beyond the key column. If you’re storing more than a few thousand records, working with data other people need to see or edit, or running queries against values in non-key columns, reach for a proper external database (Airtable, Supabase, Google Sheets for human-readable data, or a direct database connection). Make’s data stores don’t support filtering by arbitrary columns — the “Search records” operation does a full-table scan filtered client-side, which is slow and credit-expensive at scale.

    Before you build with data stores: the free Builder’s Companion Kit includes reference cards for Make’s core features — including a data store cheat sheet — plus six importable scenario blueprints. Get the free kit →

    Creating a data store and defining your structure

    In Make’s left navigation, go to Data stores. Click Add a data store. Give it a name — something specific enough to find later (processed-order-ids is better than my-store). Set the data storage size; the default is 1 MB.

    Next, define your structure. Each row in the structure becomes a column:

    • Name — the column name your modules will reference.
    • Type — text, number, boolean, date, time, date-time, array, or object (object means a nested set of key-value pairs).
    • Is Key? — mark one column as the key. Make uses this for lookups and for the upsert behavior of “Add/Update a Record.” If you don’t set a key, Make uses an auto-generated numeric Key field.
    • Required — if checked, Make will error if a scenario tries to write a record without that field.

    Design tip: always set an explicit key column using a value that’s naturally unique in your data — an order ID, an email address, a combination field. Auto-generated keys make lookups awkward because you’d have to search for a record by a non-key field instead of going straight to it by key.

    You can add columns to a data store after creating it, but you can’t change a column’s type. If you need to change a type, you’ll need to create a new store and migrate the data.

    The five operations you will use

    The Data Store module in Make exposes several operations. Five cover almost every real use case.

    Add a Record. Writes a new row. If a record with the same key already exists, Make throws an error — it does not overwrite. Use this when you know the record is new and want duplicate writes to fail loudly.

    Update a Record. Updates an existing row by key. If the key doesn’t exist, Make throws an error. Use when you’re certain the record exists and want a missing record to fail loudly.

    Add/Update a Record (upsert). Writes the record if the key doesn’t exist; updates it if it does. This is the most useful operation. In most automations, you want “write this value, overwrite if it’s already there” — upsert is that behavior without needing a prior check.

    Get a Record. Reads a single row by key. Returns the record’s fields if found; returns nothing (an empty bundle) if not found. This is how you check whether a record exists — run “Get a Record,” then use a filter to check whether the bundle is empty.

    Search Records. Scans all records in the data store and returns those that match a condition. The condition is applied after retrieval — Make reads every record in the store and then filters. This is the operation to use sparingly at scale: a 5,000-record store with a search runs the condition against all 5,000 rows every time. Use it for small stores or one-time setup scenarios. For anything repeated at volume, structure your data to use “Get a Record” by key instead.

    Delete a Record. Removes a row by key. Irreversible — Make does not prompt for confirmation in a running scenario.

    Reading all records: the pagination trap

    This is the mistake that bites people building queue-style automations or data-sync scenarios.

    The “Search Records” operation — including searching with no filter, to get all records — returns results in pages. You set how many records come back per run with the module’s Limit field, and a large store is returned in pages. Make processes each page as a bundle, and if your scenario doesn’t handle pagination, it processes the first 100 rows and stops.

    The fix: in the Search Records module settings, there’s a Limit field. Set it to the maximum number of records you expect. If your store might grow, build the scenario to iterate through pages using the iterator pattern or accept that the limit needs periodic adjustment. A cleaner design for large datasets is to structure your key so you can retrieve records one at a time by key rather than scanning.

    The second trap is writing to a data store while iterating over it. If your scenario reads all records, processes each one, and deletes records as it goes, Make may re-read pages mid-iteration and either miss records or double-process them. Safe pattern: read all records first (into an array aggregator), then process each record from the aggregated list, then delete. That way your read is complete before any writes happen.

    Using data stores across multiple scenarios

    A data store isn’t locked to the scenario that created it. Any scenario in your team can read from or write to any data store in the same team account. This is the feature most documentation underplays.

    The practical implications are significant. You can build a “writer” scenario that collects data from several sources and normalizes it into a data store, and a separate “reader” scenario that runs on a different schedule and consumes that data. You can use a data store as a shared configuration table — one scenario reads a set of settings from the store, another updates them via a webhook trigger. You can implement a simple mutex by checking for a flag in a data store before a scenario proceeds.

    Concurrency caveat: Make does not lock a data store record while a scenario reads it. If two scenario runs execute simultaneously and both read-then-write the same key, you can get a race condition — the second write overwrites the first without seeing it. For most small-operator use cases this doesn’t matter. If you’re building something where simultaneous runs are likely and the data must be consistent, either design the key structure so each run writes a distinct key, or ensure the scenario is set to run sequentially (Make’s scenario settings have a “Sequential processing” option for this).

    Related: if your data store use case is really about reliable state across retries and error handling, the companion article on Make error handling covers the full picture of how Make persists (or doesn’t persist) bundle state when scenarios fail.

    The real limits: size, records, and what happens when you hit them

    Data stores have two limits that matter: storage size and the number of data stores per team.

    Storage size. Each data store has a maximum size in megabytes, set when you create it. The default is 1 MB. You can increase it at creation time or by editing the store later, up to the per-store ceiling your plan allows — 1 MB by default on the entry Core plan, more on Pro and Teams, and custom on Enterprise (check make.com/pricing for your plan’s current figure). When a data store hits its size limit, Make throws a “Data store is full” error on the next write attempt. The scenario doesn’t partially succeed — the write fails and the scenario errors. Monitor your data store sizes in the Data Stores panel; Make shows current usage versus the limit for each store.

    Number of data stores. You can create up to 1,000 data stores per organization, regardless of your plan. If you hit that limit, Make won’t let you create a new store. The fix is to either upgrade your plan or consolidate stores — multiple logical “tables” can live in the same store if you use a composite key (e.g., prefix the key with the entity type: order:12345 vs customer:67890).

    Record count. There’s no hard record-count limit independent of the size limit — you can have as many records as fit in the allocated megabytes. A 1 MB store with lean text records can hold several thousand rows. A store with records containing long text fields or nested objects fills up faster. Design accordingly: store IDs and compact values, not full document content.

    What happens when you hit a limit. Make throws an error on the operation that breached the limit — it doesn’t silently drop data. The scenario logs the error, and if you have incomplete execution handling enabled, the failed bundle is parked for review. This is the right behavior, but it means you need to monitor your data stores actively if they’re on a growth path. There’s no built-in Make alert for “data store approaching capacity.” If that matters to your operation, build a monitoring scenario that runs daily, reads the store’s current size and record count via the Make API — the data store GET endpoint returns size, records, and maxSize — and sends an alert if usage exceeds a threshold.

    Quick reference

    Operation What it does Error if missing? Use when
    Add a Record Creates a new row Yes — errors if key exists Record is guaranteed new
    Update a Record Updates an existing row by key Yes — errors if key missing Record is guaranteed to exist
    Add/Update (upsert) Creates or overwrites No Most writes — safest default
    Get a Record Reads one row by key No — returns empty bundle Check existence; targeted reads
    Search Records Scans all rows, filters by condition No Small stores; setup/one-off runs
    Delete a Record Removes a row by key No Clearing processed queue items

    Frequently asked questions

    Can two scenarios use the same data store at the same time? Yes — any scenario in your team can read from or write to any data store in the same account. There are no locks, so if two scenario runs execute simultaneously and both write to the same key, the second write wins. For most use cases this doesn’t matter; if it does, enable sequential processing on the scenario or design keys so concurrent runs write distinct rows.

    What’s the difference between Add a Record and Add/Update a Record? Add a Record errors if the key already exists — it will not overwrite. Add/Update a Record (upsert) creates the record if it’s new or overwrites it if it already exists. In most automations, upsert is the right default because it handles both cases without requiring a prior existence check.

    How do I check if a record exists without erroring? Use “Get a Record” by key. If the record exists, Make returns it. If it doesn’t exist, Make returns an empty bundle — not an error. Add a filter after the Get module: if the bundle is empty (the key field is empty or missing), take the “new record” path; otherwise take the “exists” path.

    Can I query a data store by a non-key column? Not directly. “Search Records” lets you filter by any field, but it’s a full-table scan — Make reads every record and then applies the filter. This works fine for small stores but gets slow and expensive at scale. The better design is to set your key column to the value you’ll query most often, so you can use “Get a Record” directly.

    What happens when a data store is full? Make throws a “Data store is full” error on the next write attempt. The failing operation errors, the scenario logs it, and if incomplete execution handling is enabled, the bundle is parked. There’s no silent data loss — the error is explicit. Monitor your store sizes in the Data Stores panel and set alerts if a store is on a growth path.

    Do data stores count against my credit usage? The data store module itself counts credits like any other Make module — each time the Data Store module runs, it consumes one credit (or one credit per bundle for bundle-level operations). The data stored in the store does not consume credits; only the read/write operations do. See the companion article on Make operations vs. credits for the full credit model.

    Get the full Make reference

    The free Builder’s Companion Kit has the data store cheat sheet, a cost estimator so credits never surprise you, six importable starter blueprints, and the Production Readiness Checklist. Everything in one download — no fluff. Get the free kit →

    If you’re ready to start building, you can create a free Make account here and have your first scenario running today — the free plan is enough to learn on and test your first data store.

  • Make Error Handling: Retry, Skip, Resume, Commit, Rollback — and the Silent-Corruption Trap

    Make Error Handling: Retry, Skip, Resume, Commit, Rollback — and the Silent-Corruption Trap

    Last updated: May 2026

    Table of contents

    1. The 30-second answer
    2. A note on terminology
    3. What an “error” actually means in Make
    4. The five error handlers in detail
    5. The silent-corruption trap
    6. Handler choice vs the error route
    7. How to log errors so you actually find them later
    8. Quick reference: which handler when
    9. The old names you’ll still see in tutorials
    10. Frequently asked questions
    11. Sources

    It’s Sunday at 2am. Your phone buzzes. Your monitoring tool has flagged that the scenario you built last month — the one that processes new orders, updates inventory, sends the customer email, and creates the shipping label — stopped running 47 minutes ago. You log in. There’s a red banner: Module execution failed. You scroll down to the error log. There are dozens of entries from the same scenario. The same error. The same module. Repeated over and over before Make finally gave up.

    Welcome to error handling on Make. Most operators don’t think about it until they’re in a moment like that one. The article below is the version of error handling I wish I’d read before my first Sunday-night phone call, not the version Make’s docs hand you when you’re already in the weeds.

    The 30-second answer

    Make gives you five error handlers you can attach to any module: Retry, Skip, Resume, Commit, Rollback. Each one tells the scenario what to do when a module errors, and each one is correct in some situations and disastrous in others.

    The rough cheat sheet:

    • Retry — the module errored, park the failed bundle as an incomplete execution, keep processing other bundles, and either retry the parked bundle automatically (per your config) or wait for you to handle it manually. The right default for most production workflows.
    • Skip — drop the failed bundle entirely and continue with the next one. Marks the run as successful even though the bundle was lost. Use only when occasional data loss is genuinely acceptable.
    • Resume — the module errored, but use this default value and keep going. Useful for non-essential data. Dangerous for anything downstream modules will trust.
    • Commit — save everything that succeeded before the error. Use when partial-success is acceptable.
    • Rollback — undo everything in this scenario run as if it never happened. Use when partial-success is unacceptable (e.g., financial transactions).

    The single most expensive error-handling mistake operators make: using Resume on modules that produce data downstream consumers actually trust. The result is silent data corruption — your downstream modules run successfully on garbage data, your scenario reports “no errors,” and nobody finds out until a customer complains weeks later. Full section on this below.

    A note on terminology

    Make’s current error-handling overview and error handlers index increasingly use Retry and Skip, while older tutorials, forum posts, and some Make reference pages still mention Break and Ignore. If you’re reading older content, mentally substitute: Break ≈ Retry, Ignore ≈ Skip. The underlying mechanics are similar. The rest of this article uses Make’s current terminology.

    What an “error” actually means in Make

    A module errors when something it tried to do failed in a way it can’t recover from internally. The categories you’ll meet most often:

    • ConnectionError — couldn’t reach the external service (the API is down, your auth expired, DNS failed).
    • DataError — the external service answered, but with data Make couldn’t parse or didn’t expect.
    • RateLimitError — the external service answered with “you’re sending too many requests too fast.”
    • BundleValidationError — a field Make expected in the incoming bundle was missing or malformed.
    • IncompleteDataError — the operation partially completed; some records went through, some didn’t.
    • UnknownError — something else happened that doesn’t fit the categories above.

    The handler you attach to a module determines what the scenario does in response. The error type tells you whether that response is reasonable.

    The five error handlers in detail

    Retry

    Retry tells the scenario: “this module errored. Park this failed bundle as an incomplete execution, log the error details, and continue processing the other bundles. Either retry the parked bundle automatically per the configuration, or wait for me to handle it manually.”

    When this is right: bulk processing with transient failure. You’re iterating through 500 records. The 47th errored because of a rate limit. Retry parks bundle 47 in the Incomplete Executions queue, lets bundles 48-500 continue, and you can resume bundle 47 later — either automatically (Make’s built-in retry config) or manually from the dashboard.

    When this is wrong: rare. Retry may be less useful in a single-bundle scenario where there are no later bundles to continue processing — in that case, the parking mechanism doesn’t add much beyond what Rollback would do for clarity.

    For most production scenarios that process multiple items, Retry is the right default. It respects both the success of the work that did complete and the recoverability of the work that didn’t.

    Skip

    Skip tells the scenario: “this module errored. Drop this bundle entirely, continue with the next one, and mark the run as successful even though we lost a bundle.”

    When this is right: when occasional data loss is genuinely acceptable. Make’s own Skip handler docs frame this for cases where incorrect data has no impact on the overall outcome — maybe a non-critical log enrichment, a side-effect notification, or a record that’s safe to silently drop because it’ll be regenerated next time.

    When this is wrong: nearly everywhere else. Skip silently loses data and reports success. That’s almost always the wrong trade-off in production. If you’re tempted to use Skip because it’s easier than handling the error properly, that’s the warning sign to use Retry instead.

    Resume

    Resume tells the scenario: “this module errored, here’s a substitute output value to use, now continue as if the module had succeeded.” You provide the substitute value when you configure the handler.

    When this is right: the module is a nice-to-have enrichment. For example, you call a weather API to add a “current temperature” field to a customer record. If the weather API is down, the enrichment fails. You want the customer record to save anyway, with the temperature field empty or set to “unavailable.”

    When this is wrong: anywhere downstream modules treat the output as truth. If you use Resume to substitute a default tax rate when the tax API fails, every order that runs through during the API outage gets charged the wrong tax. Make says “no errors.” You find out at the end of the quarter.

    Commit

    Commit tells the scenario: “save everything that worked up to this point, then stop.” Useful when modules earlier in the scenario wrote real data and you’d rather keep those writes than throw them away because the later module failed.

    When this is right: the scenario processes a batch of items, some succeeded, some failed late. Commit preserves the successes.

    When this is wrong: when the work before the error and the work after were meant to happen together — a charge and a fulfillment record, an inventory deduction and a customer notification. Committing the charge without the fulfillment is a customer service problem.

    Rollback

    Rollback tells the scenario: “undo every module write in this run, including the ones that succeeded, as if the scenario had never started.” Make can only roll back modules whose underlying service supports rollback. Database writes usually can. API calls that already triggered side effects (sent an email, charged a card) usually cannot.

    When this is right: anything where partial success is worse than total failure. Financial transactions are the canonical example. If charging the card succeeded but issuing the receipt failed, rolling back the charge is safer than committing it without a receipt.

    When this is wrong: when rollback can’t actually undo what happened. Don’t trust Rollback on modules that send emails, call webhooks, or trigger external systems that don’t natively support compensation.

    The silent-corruption trap (read this twice)

    There’s a specific failure mode that costs operators real data and real money, and it’s worth its own section because it’s the most expensive mistake in this whole article.

    When you get DataError, BundleValidationError, or IncompleteDataError, the right handler is almost always Retry with manual review of the parked bundle — almost never Resume or Skip.

    Why: these three error types mean Make received data it doesn’t trust or can’t parse. Resume substitutes a fake value. Skip silently drops the bundle and reports success. Either way, the work that should have flagged a real problem instead either runs on bad data or vanishes from your awareness.

    Concretely: your CRM gets a contact with no email. Your inventory gets adjusted by a number that was supposed to be “N/A.” Your accounting export ships invoices with the wrong totals. Make reports the run as successful. You don’t find out until a customer email comes in three weeks later.

    The fix is the Retry + audit route pattern:

    1. On the failing module, set the error handler to Retry, with the scenario set to allow storing of incomplete executions.
    2. Add an error route from that module that writes the failed bundle’s full payload to a Data Store record (or sends it to a logging endpoint).
    3. Build a separate audit scenario that reads the Data Store and surfaces the failed bundles to you for manual review — Slack, email, or a daily summary, whatever fits your workflow.

    This is more work to set up than a one-click Resume. It’s also the difference between catching corruption when it happens and discovering it after it’s contaminated three weeks of records.

    The default-to-Retry rule is a strong default, not a universal law. There are deliberate cases where Skip or Resume is genuinely right — a non-critical enrichment, a side-effect logger, a record-type you’ve already decided to drop on parse failure. The rule is: if you find yourself using Resume or Skip on a module that produces data downstream modules consume as truth, stop and switch to Retry.

    Handler choice vs the error route

    There are two decisions whenever you attach error handling to a module.

    The handler choice controls the scenario flow — what happens to the bundle and to the rest of the run when the error fires. That’s the five-option choice: Retry, Skip, Resume, Commit, Rollback.

    The error route is the dotted/transparent connection you can draw out of a module that fires only when that module errors. It’s where you do the actual work in response to the error — log it, alert someone, write the failed bundle to a Data Store, transform the bundle and try a different path, write to a backup service. The last module on the error route is typically the handler that controls the flow decision above.

    The simple rule: the handler choice answers “what does the scenario do?” The error route answers “what do I do with the failure itself?”

    Most production scenarios use both. The handler is set to Retry. The error route writes the bundle to a Data Store and posts to Slack. The scenario keeps processing other bundles. You wake up Monday morning, see the Slack messages, replay the parked bundles from the Incomplete Executions screen.

    How to log errors so you actually find them later

    The default Make execution log is useful for diagnostics in the moment, but it’s a poor place to look for what failed last week. Two patterns that pay for themselves the first time something breaks:

    Pattern 1: Write failed-bundle audit records. Every Retry-parked bundle gets written to a Data Store record with a timestamp, the scenario ID, the failing module name, the bundle payload, and the error message. You can query the store later to see what’s failed.

    Pattern 2: Post to a single Slack channel for all production errors. One channel, one message per error, includes scenario name and a deep link back to the execution. You scan the channel daily. The cost is a single HTTP module per error route — almost free in credit terms.

    The Production Readiness Checklist in the free Builder’s Companion Kit includes the exact error-handler topology for both patterns as a copy-able blueprint.

    Want production-ready error-handling blueprints? The free Builder’s Companion Kit includes the Production Readiness Checklist (covers error-handler setup as one of its sections) plus six importable scenario blueprints, each pre-wired with the Retry + Data-Store audit pattern. Get the kit →

    Quick reference: which handler when

    Situation Right handler Why
    Enrichment from a non-critical API Resume (with a sensible default) Downstream doesn’t care if it’s missing
    Tax / pricing / financial data from an external source Retry or Rollback Wrong number is worse than no number
    Bulk processing of independent items Retry Park failures, keep processing successes
    Single-item scenario, partial completion unacceptable Rollback Treat as all-or-nothing
    Single-item scenario, partial completion acceptable Commit Save what worked, accept the rest failed
    Side-effect call where data loss is truly fine Skip Real use case but rare
    DataError, BundleValidationError, IncompleteDataError Retry (default) Resume corrupts silently — see section above
    RateLimitError Retry with backoff config Most are transient
    ConnectionError Retry with backoff config Most are transient

    The retry-count and interval mechanics interact with broader retry strategy, which is its own topic — covered in Make.com Retry Types: When to Use Each and the Gotchas That Eat Operations, the companion article in this series.

    The full error-handler reference, including the less-common error types and the exact scenario topologies, is covered in Chapter 8 of The Missing Manual for Make.

    The old names you’ll still see in tutorials

    Make’s current error-handling docs and UI use Retry and Skip, while older docs/tutorials — and even some Make reference pages — may still mention Break and Ignore. Older Make tutorials, forum posts, YouTube videos, and Reddit threads use the legacy names extensively. The mechanics are similar enough that the advice usually still works; only the labels changed.

    Old name Current name Notes
    Break Retry Both park the failed bundle as an incomplete execution and let the scenario continue. Retry adds explicit configuration for automatic retry attempts.
    Ignore Skip Both drop the failed bundle and continue. “Skip” is the clearer label for what it actually does — the bundle is lost, not just unnoticed.
    Resume Resume Unchanged.
    Commit Commit Unchanged.
    Rollback Rollback Unchanged.

    If you’re reading older Make content, do this substitution and the advice will still map to current Make’s UI. If you’re writing new content for your team or documentation, use the current names.

    The plan tier note

    The Incomplete Executions queue itself doesn’t require multiple scenarios — it’s a setting on a single scenario that parks failed bundles for manual or automated handling. The full audit pattern often does require more, however: typically a worker scenario plus a separate audit or notification scenario, and sometimes a dedicated retry processor on top of that. On the Free plan, the 2-active-scenario cap makes that architecture cramped fast. Operators running any production error-handling beyond the simplest patterns have usually outgrown Free regardless of credit count. Sign up here if you don’t have a Make account, or upgrade to Core via the same link.

    The pattern

    Most error-handling failures aren’t because the operator picked the wrong handler in isolation. They’re because the operator set Resume or Skip on everything at build time so the scenario would “just keep running,” then forgot the scenarios were silently swallowing real errors for months. The fix is architectural: default to Retry on every module that produces data anything else relies on, build the audit pattern once and reuse it across scenarios, and treat error routes as part of the scenario, not as an afterthought.

    That discipline is the difference between scenarios you check weekly to make sure they’re still working and scenarios that simply work.

    Grab the free Builder’s Companion Kit. Includes the Operations Cost Estimator, module reference cards, the Production Readiness Checklist (with error-handler topology), the Scenario Planning Worksheet, and six importable starter blueprints. One download, no upsell.

    Get the kit →

    Frequently asked questions

    What’s the difference between Retry and Skip in Make? Retry parks the failed bundle as an incomplete execution — the bundle is preserved, the scenario continues processing other bundles, and you (or Make’s automatic retry config) can attempt the failed bundle again later. Skip drops the failed bundle entirely, continues with the next bundle, and marks the scenario run as successful. Retry preserves data; Skip discards it.

    What’s the silent-corruption trap? It’s the failure mode where Resume or Skip is used on a module that produces data downstream modules treat as truth. The bad data flows downstream successfully, the scenario reports no errors, and the problem is only discovered weeks later when a customer surfaces it. The fix is to default to Retry on any module whose output downstream modules depend on, especially when the error type is DataError, BundleValidationError, or IncompleteDataError.

    Should I use Resume by default? No. Resume substitutes a value you specify when a module errors and continues as if the module succeeded. That’s safe when downstream modules don’t care whether the value is real (non-critical enrichment), and unsafe when they do (anything financial, regulatory, or customer-facing). Default to Retry; reach for Resume only when the substituted value is genuinely acceptable downstream.

    What’s an incomplete execution in Make? An incomplete execution is a failed scenario run (or a failed bundle within a run) that Make has stored rather than discarded. Incomplete executions can be retried automatically by Make’s built-in retry behavior for certain error types, retried manually from the scenario’s Incomplete Executions screen, or left in the queue for review. They consume no credits while parked — only when actually retried.

    Can I retry failed bundles manually? Yes. In the scenario’s Incomplete Executions screen, you can review the parked bundles, see why each one failed, fix the underlying issue (correct the data, reconnect an auth, wait for an upstream service to recover), and then click Retry on individual bundles. Each manual retry consumes credits for the modules that re-run.

    Does Skip cause data loss? Yes — that’s the trade-off. Skip drops the bundle entirely and continues with the next one. There’s no parking, no audit record by default, no replay path. Use Skip only when you’ve deliberately decided the bundle is acceptable to lose. If you want the scenario to continue but preserve the failed bundle for review, use Retry instead.

    What happens to a Make scenario that errors without an error handler configured? By default, if no custom error handler is configured, the scenario stops when the error fires. If incomplete executions are enabled in the scenario settings, the failed run can be stored for manual handling. If incomplete executions are disabled, Make’s default behavior is Rollback — but rollback only reverts changes in modules that support transactions. Side effects like sent emails, webhooks, and many external API calls generally cannot be undone, regardless of the default handler.

    Sources

    Verified live as of May 29, 2026:

    Brian Kasday writes The Operator’s Library for MMS Vegas — production-grade reference manuals for the tools small operators actually run. The Missing Manual for Make is the long-form companion to articles like this one.