Setting up a scheduled task
This document covers creating a scheduled task and making sure it does what you meant it to. There are two decisions — what the task is and when it runs — and one habit: looking at what it actually produced.
Nothing here has to be right the first time. A task can be switched off, edited, or fired by hand at any point. What each operation does with its own settings is documented with the operation itself — today that means Cycle counting.
Phase 1. Describing the task
A task is created from the list — Administration → Scheduled tasks — and three fields identify it.
Name. Required, and unique among your tasks. You will read it in the list, in the run history and, through them, against every document the task creates, so name it after the job rather than after the type: "Problem cells, hourly" tells you more than "Cycle counting 3".
Task type. What the task actually does. The type decides which settings appear further down the form, so choose it before you fill anything in below.
Run as. The user the task acts for. Everything it creates is authored by that user, which makes this more than a formality: it is the name a colleague will find on a document nobody planned by hand.
Below these comes the schedule, and below the schedule the settings of the chosen type. For cycle counting — which warehouse, which cells qualify, and how many documents one run may create — see Cycle counting.
Phase 2. Setting the schedule
The schedule answers one question: when should this run? You build it in the Schedule dialog, and the dialog writes back in plain language what you have built so far — "Every day at 08:00, 16:00, Europe/Kyiv" — rebuilding that sentence on every click. Read it before you save: it is the quickest way to catch a schedule that says something other than what you meant.
One rhythm at a time
A schedule follows one of three rhythms, and they are mutually exclusive.
Daily — every N days, at the hours you choose.
Weekly — the weekdays you choose, every N weeks, and, if you want, only in certain months. Leave the months empty and it runs all year round.
Monthly — the months you choose, every N months, and a rule for the day: a fixed day of the month, a day counted back from its end, or the Nth weekday.
So "Mondays and Wednesdays, in August and September, every second week" is a single weekly schedule. Weekdays and a day-of-the-month rule, on the other hand, do not combine — they belong to different rhythms, and you pick the one that describes yours.
Hours, not minutes
You choose hours, one or several, and at least one is required — the app will not save a task without it. An hour is also as fine as a schedule gets. Work that has to happen every few minutes is not work for a scheduled task.
The hours are the warehouse's
A schedule carries a time zone, shown with its offset, and its hours are read in that zone. The zone appears in the plain-language description as well, so in a company with sites in several zones it is clear whose morning the task means.
A window, if you need one
A schedule can be given the dates it starts and stops being valid, and the date its "every N" counts from. Leave them alone and the task simply runs from now on.
Phase 3. Checking that it ran
Every firing leaves a record, and the instance screen keeps that history beside the task itself. One line per firing: when it was due, when it actually started, how long it took, whether the schedule or a person started it, and how it ended.
Open a line to see what the run produced. For cycle counting that is how many cells came up due and how many count documents were made from them — which is the answer to "why are there no documents this morning": either nothing was due, or the documents already existed, or the run reached the limit you set for it.
How a run ends
A run that did its work ends Succeeded. Short of that it may still be waiting its turn, may be running, may have done part of the work, may have failed, or may have been skipped — and in the last two cases the history names the reason.
A due time is not a promise of the exact minute, which is why the history records both when a run was due and when it began. And if the system was unavailable when a run was due, the run is not lost — it is carried out later, and the history marks it as one that caught up.
Running it now
Run now fires the task immediately, without waiting for the schedule. The app asks you to confirm and says plainly that once started the run cannot be called back. From there it goes exactly the way a scheduled run goes, and it appears in the history as started by you — which makes it the sane way to test a new task instead of waiting until eight in the morning.