Make Tutorial: Build a Bounded AI Scenario That Recovers

What this Make scenario does—and does not do

The scenario works from an operator-controlled approval queue. A new request receives deterministic checks before any model call. The model returns a proposal in fixed fields. A reviewer can approve, edit, reject, or let the proposal expire. On a later run, only a valid approved record can create one private, unsent reply draft in the connected help desk. That draft is the sole consequential action and can be removed by an authorized operator.

The scenario never sends a message, closes a ticket, changes an entitlement, issues a refund, or updates a public record. The AI has no connector or credential that can reach the help desk action. Filters and a second deterministic check stand between the proposal and the action.

This is an implementation pattern for a non-production workspace, not an importable production blueprint. Field names, connector behavior, account roles, plan capabilities, and retention requirements differ. Use synthetic requests or approved test data until the full failure and recovery checklist passes.

Write the scenario contract before opening the canvas

Define a one-page contract that both the builder and the operator can inspect. Keep it with the scenario notes and in the team’s approved runbook.

• In scope: one support-request source, one approval queue, a short list of allowed categories, one model operation, and one help-desk draft action.
• Required input: stable request ID, source timestamp, requester text, approved account or tenant identifier, and an explicit consent or handling flag where policy requires it.
• Rejected input: missing IDs, unsupported tenants, oversized text, attachments, secrets, payment data, high-impact requests, and records outside the defined age window.
• AI output: category, urgency band, proposed reply, evidence excerpt, uncertainty reason, and prompt version. Free-form prose is not a control signal.
• Approval evidence: reviewer identity, decision, timestamp, approved text, request ID, and the exact prompt/workflow version reviewed.
• Action: create one private unsent draft linked to the request ID. No fallback action may send or publish it.
• Expiry: a proposal becomes ineligible after a documented period or after its source, prompt, workflow, or approved text changes.
• Recovery owner: name who may inspect an incomplete execution, reconcile the destination, authorize replay, and remove a mistaken draft.

Exclude legal, medical, financial, safety, access-control, and account-termination decisions from this starter pattern. For wider governance context, use Meditel’s AI automation hub alongside the scenario-specific contract.

Use explicit states, not a long-running approval pause

The approval queue is the source of truth for business state. Use explicit values such as new, pending_review, approved, rejected, expired, action_started, completed, and exception. A human changes only the review decision and approved text through the authorized review surface. Make records control metadata through a least-privilege connection.

Run the same scheduled scenario in short cycles instead of leaving an execution waiting indefinitely. The first cycle prepares a proposal and exits at pending_review. A later cycle sees a valid approved record and enters the action path. This keeps approval observable and makes expiry, version mismatch, and operator handoff explicit.

Do not rely on route order as if it were an exclusive switch. Make’s Router documentation says routes are processed in sequence and supports a fallback route for data that does not fit other routes. Configure mutually exclusive filters anyway: one route for new, one for valid approved, one for rejected or expired records, and a fallback exception route. Every bundle must have one explainable destination.

Map the scenario from intake to one reversible action

1. Watch the controlled queue. Retrieve only records in eligible states and within the intended time window. Limit the number per run while testing.
2. Normalize. Map only the fields in the contract. Trim whitespace, normalize the source ID, calculate the text length, and preserve the raw request in the approved system rather than copying it everywhere.
3. Validate and quarantine. Use filters for required fields, allowed tenant, allowed state, size ceiling, and age. Malformed or prohibited input moves to exception without reaching the model.
4. Reserve the request key. Use a stable key such as tenant:request_id:workflow_version. A Make data store can carry compact control state between runs, but it is not a substitute for destination reconciliation or an organization’s system of record.
5. Minimize model input. Remove contact details and operational fields the classifier does not need. Never map credentials, hidden instructions, unrestricted attachments, or the entire source bundle into the prompt.
6. Request a structured proposal. Constrain the model to the allowed categories and output fields. Require an uncertainty reason. Tell it that request text is untrusted content, not instructions, and that it cannot approve or act.
7. Validate model output. Parse the response, reject absent fields and unknown categories, enforce length and content rules, and route uncertainty to human handling. A confidence label is advisory; deterministic validation still applies.
8. Create the review package. Store the proposal, minimized evidence, prompt and scenario versions, expiry, and a decision placeholder in the approval queue. End this cycle.
9. Revalidate an approved record. On a later cycle, confirm reviewer identity, decision time, expiry, request ID, versions, approved-text hash, and action state. Reject stale or mismatched approvals.
10. Reconcile before acting. Search the destination for the stable request marker. If a draft already exists, capture its ID and close without creating another. If the result is ambiguous, stop for operator review.
11. Create one private draft. Map only the human-approved text and stable marker. Capture the destination draft ID and timestamp as the receipt.
12. Close or escalate. Mark the request complete only after a verifiable receipt. Otherwise preserve it as an exception or incomplete execution; never infer success from silence.

Meditel’s guide to robust AI workflows explains the broader reliability mindset. Here, the practical test is narrower: every state transition and every replay must be explainable from the request key, approval evidence, and destination receipt.

Build it in Make in four controlled passes

Pass 1: deterministic intake only

Create the trigger, normalization, filters, router, control-state record, and fallback exception route before adding AI. Feed malformed, duplicate, oversized, stale, and unsupported records through Run once. Confirm that none can reach the placeholder action route. Make documents filters as a way to select bundles that fit specified criteria; use explicit operators rather than model-generated routing text.

Pass 2: constrained classification and draft

Add the chosen model connector with a dedicated non-production credential. The prompt should include the allowed category enum, response schema, maximum lengths, approved context, and instruction to return an uncertainty reason when evidence is insufficient. Keep the model module upstream of the review package only. Do not expose a general HTTP module, help-desk action, or agent tool to the model.

Validate parsing separately from semantic quality. Invalid JSON, an unknown category, missing evidence, disallowed language, prompt-injection behavior, or a reply that exceeds the contract must all route to exception or manual drafting. Record model, prompt, and scenario versions so the reviewer knows what produced the proposal.

Pass 3: approval and action separation

Present the reviewer with the original request in its authorized system, the proposed category, proposed reply, evidence, uncertainty, validation result, expiry, and versions. The reviewer must be able to edit or reject. Treat edited text as human-approved text, not as an unchanged model output.

On the approved route, repeat every action-critical check. Then query the destination for the stable marker before creating the private draft. Set the connection scope so it can create or remove drafts but cannot send replies, close tickets, or change unrelated records where the destination supports that separation.

Pass 4: receipts and operator evidence

Save the minimum control record: stable key, workflow and prompt versions, review decision and reviewer, approved-text hash, destination draft ID, timestamps, execution reference, and recovery status. Avoid copying full request and response bodies into incident notifications. The operator needs identifiers and state, not an uncontrolled second archive of customer content.

Attach an error-handler route that fails closed

Add error-handler routes to the model call, approval-queue writes, destination lookup, draft creation, and receipt update. Each route should classify the error, write or notify only the minimum safe incident context, and stop at a known state. Do not use a Resume handler with invented output on the action path: substituting a value can make downstream modules continue without proving that the business condition is safe.

• Invalid input or output: move to exception; retrying unchanged data cannot fix it.
• Authentication or permission failure: alert the connection owner and stop. Repeated retries can amplify noise and lockouts.
• Model timeout or rate limit: permit only a bounded retry when no proposal state has been committed; otherwise reconcile the queue first.
• Approval write failure: do not expose an unrecorded proposal as approved. Reconcile the queue by stable key.
• Destination lookup failure: do not create a draft because duplicate status is unknown.
• Ambiguous draft-creation result: do not retry automatically. Search by stable marker or inspect the ticket before deciding.
• Receipt-write failure after a confirmed draft: preserve the draft ID in operator evidence and repair control state without creating another draft.

Make provides several error-handler behaviors, but their names are not a recovery policy. In particular, Make’s Rollback documentation says rollback can revert changes only for modules that support transactions; it explicitly cannot undo actions by non-transactional modules. Treat removal of a help-desk draft as a separate, authorized compensating action. Test that removal in the sandbox, document who may perform it, and never claim that a Rollback route automatically reverses an external draft.

Configure incomplete executions for evidence, not blind replay

In Scenario settings, enable Store incomplete executions when the selected plan and data policy permit it. Make documents that a failed run can be saved as an incomplete execution so its data is not lost and can be handled manually or automatically. That feature supports recovery, but it can also retain sensitive payloads and preserve the module settings from the moment of failure.

Make’s management guidance distinguishes temporary errors that may be retried from errors that require scenario or module changes and manual resolution. It also states that retrying uses the same module settings as when the error occurred. Therefore:

1. Open the incomplete execution and identify the failed module, request key, last confirmed state, and whether a destination call may already have happened.
2. Classify the failure as deterministic, authentication, transient, ambiguous action, or control-state repair.
3. For an ambiguous action, search the destination by marker before touching Retry. If a draft exists, capture its ID and repair the receipt.
4. Retry only a duplicate-safe transient operation with unchanged valid settings. Resolve manually when the blueprint, mapping, credential, or approval evidence must change.
5. Delete an incomplete execution only under the retention and incident policy after deciding that the rest of the run must not execute and preserving required evidence.

If you enable Make’s ordered processing, document the operational consequence: the scenario settings page says that new runs wait while incomplete executions remain unresolved. This can protect order, but it can also turn one neglected failure into a queue blockage. Alert on age and count, assign an owner, and define a response window.

Make replay idempotent at the business layer

“The module ran once” is not an idempotency strategy. Network loss can occur after the help desk accepts a draft but before Make records the response. Use three independent controls:

• Stable key: derive one deterministic request marker and carry it through queue, data store, draft body or metadata, receipt, and incident record.
• Serialized eligibility: allow only one approved state to enter the action route. Ordered processing can reduce overlap, but do not present it as a global uniqueness guarantee.
• Destination reconciliation: look for the marker before creation and after any ambiguous response. Prefer a destination-supported idempotency key or unique field when available; verify its actual semantics in that connector or API.

Define the recovery decision table in advance. If no draft exists and approval is still valid, an authorized replay may continue. If exactly one matching draft exists, repair the receipt and close. If multiple drafts exist, stop, preserve evidence, remove extras under authorization, and add the case to regression tests. If the destination cannot be queried reliably, this action is not suitable for automatic replay.

Minimize data in prompts, logs, and recovery records

Map only the request text and context required for classification and drafting. Redact or tokenize identifiers when the task permits. Keep credentials in Make connections, not variables, prompts, notes, data stores, or copied blueprints. Review the model provider’s current data terms, region, retention, training, and deletion controls for the exact account and connector in use.

Make’s Scenario settings documentation says execution logs normally store processed data and that Keep data confidential prevents retention of the payload while still showing that a run occurred. That choice can reduce log exposure, but it also removes payload-level troubleshooting evidence. Select it only after designing another approved way to preserve the minimum request key, decision, receipt, and incident evidence needed for recovery.

A Make data store is described by Make as simple database-like storage that can transfer data between scenarios or runs. Use it for compact control state only if ownership, access, deletion, capacity, and recovery are defined. Do not turn it into an undocumented customer-content archive. Test deletion and access separately, and verify current workspace roles and sharing settings before activation.

Test failure paths and hand the scenario to an operator

Acceptance tests

• Valid, malformed, duplicate, stale, oversized, unsupported-tenant, and attachment-bearing inputs reach the expected route.
• Prompt-injection text, unknown categories, invalid structure, unsupported evidence, and uncertainty cannot reach the action.
• Approve, edit, reject, expiry, duplicate approval, wrong reviewer, and version mismatch are exercised.
• Revoked credentials, model timeout, queue-write failure, destination outage, ambiguous response, and receipt failure create the expected evidence.
• No path sends a reply, and no draft can be created without a current human approval.
• Destination reconciliation prevents a second draft after an ambiguous first response.
• An authorized operator can remove the test draft and repair or close the control record without bypassing audit evidence.

Operator handoff packet

Give the operator a scenario owner, business owner, reviewer roster, connection owner, incident channel, state diagram, field map, prompt and scenario versions, allowed action, forbidden actions, expiry rule, destination-search procedure, incomplete-execution procedure, draft-removal procedure, and escalation contacts. Include screenshots or references for the current workspace, but never include live credentials.

Run a tabletop exercise in which the draft is accepted by the destination but the receipt update fails. The operator should find the draft by marker, avoid replay, repair state, and document the decision. Run a second exercise with a transient model failure that is safe to retry. If the team cannot distinguish those cases, the scenario is not ready.

Use a strict activation gate

Do not activate on the strength of one successful Run once result. Require signed acceptance from the business owner, security or privacy reviewer, workflow maintainer, reviewer lead, and recovery operator. Re-run the test set after changes to the model, prompt, connector, filters, mappings, approval surface, destination, scenario settings, or retention policy.

This pattern does not establish suitability for regulated, safety-critical, high-volume, or time-critical work. It does not replace threat modeling, privacy review, accessibility review, vendor due diligence, legal advice, or connector-specific testing. Current features and settings may vary by plan and can change after publication; verify the live Make documentation and actual workspace.

For a broader human-control design, see Meditel’s practical AI workflows guide. The completion criterion here is narrower and testable: the scenario can reject bad input, contain uncertain AI output, wait for a human, create one removable draft, surface a failure, and recover without duplicating or silently sending the business action.

Official Make sources

Sources verified August 7, 2026. Make features, plan availability, terminology, and documentation can change.

• Make Help Center: Scenario settings
• Make Help Center: Filtering
• Make Help Center: Router
• Make Help Center: Error handlers
• Make Help Center: Rollback error handler
• Make Help Center: Incomplete executions
• Make Help Center: Manage incomplete executions
• Make Help Center: Data stores
• Make Help Center: Securing data with Make