An organizer receives a new event notice every week and manually prepares a short FAQ. Build a workflow that reduces repetitive drafting while keeping unsupported answers out of the final result. Begin with invented notices so you can test failures without touching anyone's inbox.
Before you begin: Complete the prompting and responsible-use lessons. A spreadsheet and text assistant are enough.
Define a small record
Create a table with columns for notice ID, version, source text, draft FAQ, review status, and review notes. Give the first notice a stable ID such as sketch-walk-01 and version 1. The ID identifies the event; the version distinguishes changed notices.
Use this source: “Sketch walk, Sunday 14:00, north park entrance. Bring a notebook. Cancelled during a thunderstorm.” Your FAQ asks when and where to meet, what to bring, what happens in bad weather, and whether materials are provided.
The last question is deliberately not fully answered. A useful workflow must represent that gap instead of producing five confident answers for the sake of a complete-looking table.
Run the workflow manually once
Copy the source into a text assistant with this task: answer each FAQ question using only the notice, include the supporting phrase, and mark unanswered questions as “not specified.” Save the draft in the table with review status “pending.”
Review each answer against its supporting phrase. Confirm the precise weather condition. “Bad weather” is broader than “thunderstorm,” so the answer should preserve the actual rule. The notice says to bring a notebook; it does not establish that other materials are provided.
Mark the draft “approved” only after correcting unsupported statements and resolving any required missing facts. This lesson ends at an approved draft. Sending or publishing is a separate action in your actual workflow.
What should happen after only part of the work succeeds?
A signup workflow makes several changes: it stores a registration, reserves a place and sends a confirmation. Those actions do not necessarily succeed together. If the email service fails after the reservation is saved, rerunning everything may create another reservation while the user still sees no confirmation.
Write down the state after each step and the next action allowed from that state. A retry should continue or safely repeat work, with an identifier that ties attempts to the same signup. The challenge is to design this behavior before choosing the visual automation tool, because the tool cannot infer what a duplicate booking means for your workshop.
The place is reserved successfully, but the confirmation email fails.
Retry the notification for the same signup instead of creating a new signup.
The person receives one reservation and a recoverable confirmation path.
Add a controlled trigger
If you use an automation builder, connect a new or updated table row to a model action and then a draft-storage action. Use a test table first. The exact setup depends on the builder and account; use its current documentation for connector permissions and field mappings.
Map the source-text field explicitly. A common integration mistake is sending only a file name or row ID instead of the actual text. Inspect the input received by the model step before judging its answer quality.
For a connector-free version, run the same steps by hand. You can still learn the system design and complete the project without a paid automation plan.
Make retries and revisions visible
Use the pair of notice ID and version as the draft's identity. If the same trigger runs twice, the workflow should reuse or update the pending draft for that version rather than create two indistinguishable items. In a real concurrent system, this needs an atomic storage constraint or equivalent platform support; a casual search-then-create sequence can race.
When the source changes, create a new version and require review again. An approval of Sunday's 14:00 notice does not authorize a revised 15:00 announcement. Keep the old version as a record of what was reviewed.
Exercise the failures
Test an empty source, a missing location, two contradictory start times, and a model-step timeout. The empty source should stop before generation. The missing and conflicting facts should appear as review issues. A timeout should leave a visible failed or retryable state, not an approved empty draft.
Use a bounded retry policy for temporary failures. Re-running an external publishing action would require separate duplicate protection; creating a draft is a safer first integration because the person can inspect it before any wider effect.
Demonstrate the completed project
Show one approved draft, one draft with an unresolved fact, and one recorded failed run. Explain how a reviewer finds the source and how a changed notice invalidates the previous approval.
Check the learning outcome
The project succeeds when another person can trace an answer to the notice, see what is missing, and distinguish a new revision from a repeated run. Merely receiving generated text is not the completion criterion. If you performed only the manual version, label it accurately; do not claim that a scheduled integration was tested.
Practice with feedback
Build a no-code workflow you can audit
When a sign-up form is submitted, you want a row added to a sheet, a confirmation sent, and an alert if the class is full.
Run a workflow by hand once, then add a trigger and make retries visible.
Make the decision before reading the feedback
Check your understanding
Now make something you can check
Specify the workflow: the record, the steps, the retry safety, and the failure routes.
These notes stay on this page. Download them before leaving.
Check your reasoning against these points
- The record has a stable unique key
- Every step states what happens if it runs twice
- At least three distinct failure routes are designed, not just logged
- The recovery proof is an action you can perform, such as killing the run mid-way
Compare with a worked answer
Compare the decisions and the evidence. Your wording can be different.
The record: submission_id (UUID from the form), name, email, class_slug, submitted_at, status. submission_id is the key.
Steps, in order: 1. Upsert a row in the sheet keyed on submission_id, status=received. 2. Check remaining places for class_slug. If zero, set status=waitlisted, else decrement and set status=confirmed. 3. Send the email matching the status, then set email_sent_at.
For each step, what a repeat would do: 1. Upsert: overwrites the same row. Safe. 2. Decrement: NOT safe on its own. Guard it by only decrementing when status is still 'received', so a repeat is a no-op. 3. Email: guarded by email_sent_at. If it is set, skip.
Failure routes: class full -> status=waitlisted, member gets the waitlist email with their position, organiser gets a daily digest, not an alert per person. missing email -> status=needs_contact, row flagged in the sheet, no send attempted, organiser sees it in the flagged view. sheet unavailable -> retry three times with backoff; if still failing, write the submission to a fallback queue and alert, because losing a sign-up is worse than a duplicate.
How I would prove recovery works: submit a test form, kill the run between steps 2 and 3, then re-run it. The correct result is one row, one place taken, one email. I would run this before trusting it with a real Saturday.
When you are signed in, opening the challenge carries your edited working notes into its draft in this browser. The challenge has its own completion record. Practising here does not award points or mark it complete.
Next, we will use a source notebook to explore a collection of documents while keeping the distinction between retrieved evidence and a generated synthesis.
Further reading
The NIST AI Risk Management Framework provides context for meaningful oversight. Use the official documentation of your chosen automation platform for its actual trigger, connector, and storage behavior.