What you will learn Not a chapter to read but one to do. Set up one recurring schedule, then make it fail on purpose to see what happens when nobody is watching.
Keep that last line. Make your first schedule an email send and the first thing you learn will be something you cannot undo.
Do not go straight to recurring. Queue a single run.
Check the second. A mismatched timezone, or a different reading of "tomorrow," is the most common surprise on a first schedule.
Once the single run worked, turn the same instruction into a repeat.
HyperTeamsEvery Monday at 09:00| To check | |
|---|---|
| Is the next run time shown? | □ |
| Is there a pause? | □ |
| Does the schedule survive a pause? | □ |
Press it and see for yourself on the third. Mistaking pause for delete is a common reason people never use it.
This is the point of the exercise. Nudge the instruction slightly off so it fails.
| What happened | Verdict |
|---|---|
| Left "no data" and stopped | ✓ properly designed |
| Produced an empty table and marked itself complete | the dangerous one |
| Filled in plausible numbers | fix the instruction immediately |
If you got the second or third, add these two lines and run it again.
When a person is watching, the person stops it. A schedule has no such person.
1. Why make your first schedule something that does not go outside?
So a mistake can be undone. First schedules usually have the time or the scope slightly wrong, and if that is an email send, it cannot be taken back.
2. Why make it fail deliberately?
To see what gets left behind when nobody is watching. An empty result marked complete, or invented numbers, are things no one catches — unlike work a person is sitting in front of.
3. What must a scheduled instruction always contain?
The behaviour on failure. An instruction to leave it alone rather than produce something is what stops wrong output from quietly accumulating.
Next, the ways in from outside → Channels — the ways in
□ 25 minutes□ A workspace with at least one tool enabled□ One small job you repeat weekly or daily · something that looks things up and tidies them — start with nothing that goes outsideTomorrow at 09:00:Count the enquiries logged over the last 7 days by type and lay them out in a table.Use only the numbers you retrieve; do not estimate.□ Did it appear in the queue?□ Is the run time the one you meant?□ Can you cancel it right now?Point it at something that does not exist: "enquiries logged over the last 7 days" -> "return approvals logged over the last 7 days" (if no such data exists, leave it as is)If you cannot find the data, do not produce a result — leave only "no data".Use retrieved numbers only; leave blanks where there are none.□ You turned off or deleted the practice schedule□ For anything you kept, you checked the next run time□ You put the two failure lines into the real schedule□ You went queue-once first, then recurring□ You confirmed pause is not delete□ You made it fail and saw what got left behind <- skip this and you did not do the exercise□ You wrote the failure behaviour into the instruction