# Automation evaluation pack

Original editorial exercises by Use AI for X. Proposed evaluation, not performed: the expected files contain acceptance rules, and the observation columns are blank. No platform has been run for this pack. Opening or downloading it sends no events.

Start from https://useaiforx.com/for/workflow-automation/#example . Use disposable test assets and example.com addresses. Never send confirmations, emails or Slack messages: the destination is a test record or a local note. Files contain synthetic data and no executable automation.

## Choose the exercise

- **Ten orders:** `order-inputs.json`, `order-expected.json`, `order-run-ledger.csv`. This is the task page's branching + AI + write/retry exercise.
- **Five form events:** `form-inputs.json`, `form-expected.json`, `form-observations.csv`. This separate exercise tests duplicate IDs, missing input and formula-like text. It needs no AI step. Its results must not be merged with the order exercise.

## Check access before building

Record your actual tool, plan, trigger and destination, plus any model-provider account and usage charges. The order exercise needs routing, an AI step, a write and a retry guard in the same available configuration. If one is unavailable, stop that stage and record it; do not silently upgrade or treat it as an AI failure. Use the linked profiles for dated plan evidence, then check the current account. The pack does not promise that every listed tool can execute the complete flow for free. Self-hosting also requires a server and maintenance.

## Ten-order exercise

1. Map the five named input fields. Flag O-03 and O-07 for missing email, and O-09 for amount zero. Those three must never reach the AI step.
2. For each of the other seven, ask for one confirmation note containing only the supplied product and amount. Save it to the test destination; do not send it. Keep the input ID through every step.
3. Before O-05 reaches the write, deliberately make its test destination unavailable. Keep the failed run, restore access and retry using the platform's documented mechanism. The two O-05 ledger rows distinguish first failure and retry.
4. Check for an existing order ID before a retry writes. A lookup alone can race with another writer. For this exercise use one serialized writer or a destination with a unique key; record any limitation in the chosen setup. Do not claim exactly-once delivery based on a single successful run.
5. Read billed units from the actual run history; keep tasks, credits, executions and external model charges separate. Retried earlier actions may consume more usage. Record the real run path and AI invocation count rather than assuming the retry resumes at the write.
6. Pass only with seven notes, three review entries and no duplicate destination IDs. Inspect note content too: a technically successful write containing an invented shipping date fails. The actual observations remain blank until you run the exercise.

## Five-event form exercise

The outer `events` array preserves sequence; send each `payload` separately. The repeated A02 is the same event delivered twice, not a new customer request. Use fresh empty test assets for each run. The same person may submit a new request with a new event ID, so deduplicate by event ID rather than email.

1. Validate required fields before writing. A03 must create one visible review item and no sheet row.
2. Send both copies of A02 immediately one after the other. Check the actual destination for duplicates; one run without a duplicate does not prove a race cannot happen.
3. Compare ordinary parallel processing with an explicitly serialized test configuration where supported. Make documents parallel processing by default and a **Process data in order** setting. This only covers writers controlled by that configuration; another workflow can still race. Source: https://help.make.com/webhooks (checked 2026-09-27; processing order, not plan availability).
4. Keep A04's `=2+2 please` exactly as text. The input and expected files use JSON so opening them does not execute a spreadsheet formula. When writing through Google Sheets API, `RAW` stores values without parsing; other connectors must expose an equivalent text-preserving option or be recorded as unconfirmed. CSV quoting alone is not a formula guard. Source: https://developers.google.com/workspace/sheets/api/reference/rest/v4/ValueInputOption (checked 2026-09-27).
5. Pass with exactly A01, A02 and A04 in the sheet, A03 on the review list, and the A04 cell displayed exactly as supplied rather than calculated. Record both the displayed value and cell type; an altered string is not an exact-text pass.
6. In a separate clean run, make the test write fail for A01, restore access and retry. Keep both attempts and require one final A01 row. Inspect failure visibility before accepting recovery. n8n documents error workflows and intentional failure using Stop And Error; this is behavior documentation, not proof that your workflow is configured correctly. Source: https://docs.n8n.io/flow-logic/error-handling/ (checked 2026-09-27).

## Handover

Keep the inputs, expected files, completed observation logs, workflow export or mapping screenshots, and a short runbook stating who owns failures, how to retry, the log-retention limit on the actual plan and where to find usage. Remove test connections when finished. A workflow-status badge is not enough: inspect destination rows, text and the failed/retried event.

Do not fill observations with the expected answer. Import the blank CSV logs as text and preserve formula-like values as text when recording them. Your completed files stay with you.