Make incomplete executions: retry or resolve safely

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Inspect the stored failure before choosing an action

Make can store unfinished runs when Store incomplete executions is enabled; this setting is disabled by default. The Incomplete executions tab provides access to these runs. Make documents retrying temporary failures using the original configuration, while manual resolution is appropriate when mappings or module settings need correction. A retry starts at the module that failed. The scenario must be active for retrying incomplete executions.

Our recovery recommendation is to classify the business operation before clicking a bulk action. A temporary read failure, a malformed record and a write with an uncertain result should not automatically receive the same treatment. Record the event ID, failed module, observed error and external outcome where available.

A three-case triage example

Imagine a fictional enquiry workflow that creates a CRM record and then schedules a follow-up. Case A fails while reading reference data during a temporary outage. Case B fails because the follow-up mapping lacks a required owner. Case C reports a timeout while creating the CRM record and gives no clear evidence whether the write completed. These examples describe possible classes of failure, not results from a live Make account.

A recovery checklist

1. Open the incomplete execution details and identify the failing module and input.
2. Compare the failed step with completed destination actions. Preserve their record IDs.
3. Choose retry for an unchanged configuration only when another attempt can reasonably succeed.
4. Use the documented manual-resolution flow when a configuration or data correction is needed.
5. Recover a small, understood case first and reconcile its business outcome.
6. Only then consider a group of failures that share the same cause and recovery policy.

Do not assume that changing the current scenario automatically changes the configuration used by a stored retry. The official management guide distinguishes retrying the existing configuration from resolving an execution that requires changes. Keep this distinction in the operating notes so another person does not repeat an already known mapping error.

Reconcile the whole business outcome

For the enquiry example, success means one correct CRM record with one correctly assigned follow-up. A resolved technical execution is an observation to compare with that contract. Use a durable enquiry ID to check the destination rather than counting all records created during a broad time window.

If the destination lacks a reliable lookup or uniqueness rule, uncertain writes may require manual investigation before replay. Document that limitation instead of assuming the automation platform makes every external action repeat-safe.

Do not delete unexplained work

Make's management guide says deleted incomplete executions cannot be restored. Our recommendation is to delete only after an authorized owner has established that the remaining work is unnecessary or already reconciled elsewhere. Keep a minimal decision record without copying sensitive payloads into an unprotected spreadsheet.

Accept the recovery procedure when an operator can explain the chosen action, identify completed side effects and prove the final destination state on synthetic cases. No recovery guarantee, account storage allowance or live test is claimed here.