Compute
Create a schedule
Write a schedule in the released trigger dialect, set the time zone, overlap, misfire and catch-up rules, then review the plan before you activate it.
Before you start
You need an administration credential, one workflow you have already run by hand, and a scoped automation identity for it to run as.
Run the workflow manually first. A schedule repeats whatever you gave it, including a request that was wrong in a way nobody noticed.
Write the trigger in the released dialect
Schedules accept one released trigger dialect. Describe the schedules family to read the current dialect, the fields it accepts and the release it belongs to.
Do not port an expression from another product and assume it parses. A dialect that looks familiar can differ on ranges, step values and the meaning of the last field.
If the dialect cannot express what you need, say so in a simpler trigger and split the work into two schedules. A trigger you can read aloud is a trigger you can review.
Decide the six behaviors that bite later
Set all six explicitly. A value you leave unstated is still a decision, made by the default rather than by you.
- Time zone. Name the zone the business cares about, not the zone your laptop is in.
- Daylight saving. On a transition day a wall-clock time can vanish or happen twice. Declare whether a missing time is skipped or shifted, and whether a repeated time runs once or twice.
- Overlap. Decide whether a new occurrence may start while the previous one is still running, or must wait, or must be dropped.
- Misfire. Decide what happens when an occurrence could not start on time, and how late is too late to start at all.
- Catch-up. Decide whether occurrences missed during a pause or an outage run afterwards, and how many.
- Maximum runs. Set a ceiling on total occurrences. An unbounded schedule is the one that surprises your invoice.
Overlap and catch-up interact. Catch-up with overlap allowed can start several occurrences at once, which is rarely what a finance owner expects.
Review the plan before you activate
Plan the change, read the plan, then apply it. The plan states the resolved trigger, the identity it runs as, the profile values and the bound you are accepting.
Read the resolved next occurrence times in the plan, not the expression you wrote. The resolved times are what will actually happen.
Approve only after the bound looks like something you would sign for a month of unattended runs.
Confirm success
Read the schedule back after the apply. The read-back is the current state; the apply response only says your request was accepted.
Check three things on the read-back. The state is active, the next occurrence times match your intent, and the identity is the one you meant.
Then watch the first real occurrence. Its events show admission, the fresh quote and the job it created.
When an occurrence does not run
A due occurrence can still be refused, and the refusal names why and what to do next. Read the reason before changing the trigger.
- A budget refusal means your spend authority is exhausted, not that the schedule is broken. Raise or renew the ceiling.
- A capacity refusal is about this moment. The next occurrence is unaffected.
- An admission refusal about the request itself means the schedule needs a new plan, because the workflow or its inputs moved.
If an expected occurrence is simply absent, check the pause state and the catch-up rule first. See why a scheduled run did not happen when the events do not explain it.