The six-stage automation model
The simplest useful model is Trigger - Fetch - Generate - Format - Publish - Log. The word "generate" can mean an AI response, a calculation, a document transformation or any other processing step. Not every workflow needs AI. The six stages are valuable because they make hidden assumptions visible.
| Stage | Question to answer | Evidence of success |
|---|---|---|
| Trigger | What event or schedule starts the work? | A run identifier and start time |
| Fetch | Which approved source supplies the input? | Validated input with source and retrieval status |
| Generate | What rule, model or calculation transforms it? | Output that meets a defined structure |
| Format | How must the result be prepared for its destination? | Correct fields, length, encoding and presentation |
| Publish | Where is the result delivered, and who can see it? | Destination response or saved draft identifier |
| Log | What should an operator know later? | Timestamp, outcome, failed stage and safe error summary |
A weak design says, "Use AI to post every morning." A testable design says, "At 7:00 a.m. on weekdays, retrieve one approved topic record, prepare a draft of no more than 180 words, validate required fields, send it to a private review destination and log the record ID and outcome." The second statement can be tested before anyone depends on it.
Write the operating rules before writing code
Begin with the manual process. Observe who starts it, where the source information lives, which judgement calls are made and what counts as complete. Automation should remove repeatable handling, not hide an undefined decision.
Minimum requirements checklist
- Name the workflow owner and the person who handles failures.
- Define the trigger, timezone and acceptable delay.
- List the approved input source and required fields.
- State the transformation rule and prohibited output.
- Choose a private test destination before any public destination.
- Set duplicate-prevention and retry rules.
- Define which records may be logged and how long they are retained.
- Document a manual fallback for important work.
For an AI-assisted step, add an acceptance rule. A useful rule may require a title, three factual points derived only from supplied input, a source reference and a maximum length. If the output cannot be validated automatically, route it to a human draft queue rather than publishing it directly.
Choose an implementation path that matches the job
| Path | Good fit | Important caution |
|---|---|---|
| Managed script platform | Spreadsheet, email, calendar or document workflows owned by a small team | Triggers may run under the creator's account; ownership and permissions must be documented |
| Repository workflow | Versioned scripts, scheduled processing and reviewable changes | Schedules, runtime limits and secret access must be tested in the hosted environment |
| Application integration | User-specific records, authenticated actions and product workflows | Requires access control, server-side validation, monitoring and a clear data model |
Google documents how installable Apps Script triggers behave, including account ownership and failure notifications. GitHub documents its workflow syntax and scheduled events. Use the official documentation for the platform you select because schedules, permissions and limits can change.
Platform-neutral pseudocode
on approved trigger:
create run identifier
fetch one eligible record
stop safely if no record exists
validate required fields
transform input under defined constraints
validate output structure
save to private review destination
mark source record as processed
log outcome without credentials or sensitive contentThis is intentionally architecture, not production code. Authentication, rate limiting, concurrency, privacy and destination-specific validation must be designed for the actual system.
Separate secrets, settings and content
| Information | Examples | Where it belongs |
|---|---|---|
| Secret | API token, signing key, database password | Protected secret store, never committed or printed |
| Configuration | Timezone, destination ID, word limit | Environment variable or reviewed configuration |
| Content | Approved topic, source text, review status | Authorised content store with suitable access controls |
| Operational log | Run ID, stage, status, safe error code | Restricted log with retention rules |
GitHub distinguishes secrets for sensitive values from variables for non-sensitive configuration. The same separation is useful on other platforms. Do not assume masking will repair a secret that has already been committed. Revoke and replace an exposed credential, then remove it from history using the platform's incident procedure.
Minimise personal data. A workflow that sends a general training reminder may need a delivery address, but it rarely needs a participant's date of birth, identity document or complete profile. Fetch only the fields required for the stated task.
Worked example: a reviewed daily learning digest
Goal: prepare one short learning digest from an approved topic list and send it to a private reviewer. The workflow must never publish automatically.
- Trigger: run once each weekday in the organisation's documented timezone.
- Fetch: select the earliest record whose status is "approved" and which has not been processed.
- Generate: create a title, a short explanation and one practice question using only the approved source text.
- Format: require all three fields, enforce the length limit and attach the source record ID.
- Publish: save as a draft or send to a private review channel.
- Log: record the run ID, source ID, destination response and final status. Do not log the credential or full private message.
Duplicate control: write a processing lock before generation, then mark the record complete only after the destination confirms receipt. If delivery fails, release or expire the lock according to a documented retry rule. Human control: the reviewer checks factual accuracy, tone, source use and audience suitability before any public posting.
Test failure, not only success
| Test | Expected behaviour |
|---|---|
| No eligible input | End normally and log "no work" without sending an empty message |
| Missing required field | Reject the record and identify the field for correction |
| Unexpected output | Do not deliver; save a safe validation error |
| Destination unavailable | Retry within a capped policy, then alert the owner |
| Two runs overlap | Only one run claims the source record |
| Credential revoked | Stop, alert the owner and avoid exposing the credential in logs |
Use a test account, test dataset and private destination. Start with manual execution, then enable the schedule. Review the first several runs and define a regular check for silent failures. Important automations should have a visible owner, a current runbook and a manual fallback.
Practice: design before you build
Choose one repeated task such as collecting assignment reminders, preparing a weekly stock summary or assembling a meeting-action draft. Write a one-page design containing the six stages, owner, input fields, validation rules, data sensitivity, duplicate control, failure alert, test cases and manual fallback. Then ask another person to identify one assumption that is still hidden.
Build a complete example with the Google Sheets, Gemini and Telegram topic-to-content lab, including the corrected function order and real classroom troubleshooting. For prompting practice, see the AI and Prompt Engineering guide. JENECONK Digital Academy learners can also submit a training assignment for assessment and feedback.
Frequently asked questions
What are the main stages of an automation workflow?
Trigger, fetch, generate or transform, format, publish or deliver, and log. Treating them as separate stages makes testing and ownership clearer.
Should API keys be written inside automation code?
No. Store credentials in the platform's protected secret facility and expose each secret only to the step that needs it.
Does an AI step make an automation reliable?
No. Reliability depends on validation, review, logging, retry rules and human ownership. AI output can still be incomplete or unsuitable.
What should be tested before launch?
Normal input, missing input, duplicate runs, invalid output, service failure, permission failure and recovery. Confirm that logs are useful without leaking secrets or personal data.