Add a clock, rehearse it, and prove it fired — transcript

Presentation 2 of 2 in Which automation runs on your tenant, and how to switch one on · about 8 minutes · for the whole-system operator — you run the books.

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This presentation is for you if you have agreed a job your tenant should run on a timetable and now have to make it happen. In about eight minutes you will add the clock, test it without surprises, and know how you will notice if it ever stops.

Step 1 — Decide what you are switching on, and who decided

After this step you will know the question to settle before you open the Scheduler. A clock starts a job on your tenant, for real, on a timetable, until someone stops it. Which jobs a group like GadgetSphere should run is not something a screen or this presentation can decide, and no page lists them yet, so agree it with BigLedger, job by job. Our example is one the product already gives every new tenant: the monthly aging snapshot. Each time it runs, it stores the balance still open on each final document dated before the first, labelled as at the last day of the previous month, and that is what the historical aging reports read. GadgetSphere’s tenant is older than that default, so no month-end photograph is being taken. You will add the clock exactly as a new tenant has it.

Reference: How Work Actually Runs — As a scheduler — cron, per tenant, with a run log

Step 2 — Find the job in the picker

After this step the right job is on the form. Open the Scheduler applet and press the plus button to add a row. The Scheduler Code box does not take typing: click it, and the Select Processor picker opens, listing each job’s Code, Name, Type and Status. Search for MONTHLY_GENERIC_DOC_HISTORICAL_AGING_PROCESSOR and pick it. Choose carefully, because the code cannot be changed once the row is saved; a wrong code means deleting the row and starting again. If the job you agreed is not in the picker, stop and send BigLedger its code. Remember from the last presentation that the picker is the platform’s register, so a job missing from it can still be one the scheduler runs.

Screen: Scheduler applet, a new row, the Select Processor picker with its Code, Name, Type and Status columns

Reference: Scheduler — Screens and menus

Step 3 — Create it inactive, with the properties it needs

After this step the clock exists and cannot fire. Give it a Scheduler Name you will recognise, such as monthly aging snapshot; it is saved in capitals. Set Status to INACTIVE. That is the whole safety of this procedure: only active rows are read, so an inactive clock never fires while you check it. Now open the Json tab, named for the text format it is written in. It holds the properties the job receives on every run, filled in from the job’s own defaults when there are any. The aging snapshot takes none, so leave it as it is. Other jobs do, a switch for each check the inventory watchdog makes, for example, and whatever this tab holds is what the job acts on. One caution: if a job’s properties include a password, key or token, never save that clock from Edit; ask BigLedger to change it, or the job stops working at its next firing.

Screen: Scheduler applet, Create, the Details tab with Status set to INACTIVE, and the Json tab

Reference: Scheduler — Trying it safely before you need it

Step 4 — Write the timetable

After this step the clock knows when it is due. Open the Cron Expression tab. The editor writes a standard five-field expression, minute, hour, day of the month, month and day of the week, and shows it on the Expression line underneath. It starts at midnight every day. Use the Monthly tab to choose day one of every month and read the Expression line to confirm it. A new tenant’s own clock for this job reads 0 1 1 * *, one o’clock on the first, and that is what you copy. Then press CREATE. The platform measures each next occurrence from the clock’s Last Run Date, which is set to the moment you create the row, so a new clock never catches up on a time that has already passed. Which time zone the hour is read in is not yet stated anywhere, so treat the hour as approximate until you have seen a firing.

Screen: Scheduler applet, Create, the Cron Expression tab and its Expression line

Reference: Scheduler — Configuration

Step 5 — Rehearse with Run Now, or decide not to

After this step you will know what Run Now proves, and when not to press it. Open the new row. Run Now puts the job in the queue and runs it at once, and it leaves Last Run Date alone, so the timetable is not disturbed. But it is not a dry run: the job does exactly what it does on schedule. Its messages also say less than they seem. An error means the job could not be started at all. The success message means only that the job was handed over, because a job that fails part-way still reports success. For the aging snapshot, do not press it. Run on the twenty-eighth, it stores last month’s month-end photograph from today’s balances, and no later run replaces a month already stored.

Screen: Scheduler applet, Edit, the Details tab with the Run Now button

Reference: Scheduler — Trying it safely before you need it

Step 6 — Switch it on, and know when it first fires

After this step the clock is live, and its first firing will not surprise you. Open the row and set Status to ACTIVE. Before you press SAVE, open the Cron Expression tab and read its two lines. Current Expression is what the clock holds now; Update Expression to is what SAVE will write, so they should match unless you meant to change it. Then save. The first firing is still measured from the moment you created the row. If an occurrence fell while the clock was inactive, it fires on the next tick after you save. So a snapshot clock created on the twenty-eighth and switched on the next day waits for the first. One created before the first and switched on after it fires at once, and takes the same late photograph Run Now would.

Screen: Scheduler applet, Edit, the Cron Expression tab showing Current Expression and Update Expression to

Reference: Scheduler — Lifecycle and effects

Step 7 — Prove it fired, and keep proving it

After this step you can prove the clock works, and will notice if it stops. Before the first, open the Debtor Report applet’s Historical Debtor Report as at this month’s end and confirm it is blank; note one customer’s open balance. After the first, open the Scheduler listing: Last Run Date should now fall on the first. A moved date proves only that the clock fired, so open the report again: the balance should be there. If the date has not moved and the row is active, look at another active clock that was also due. If that one moved, the scheduler does not recognise your code; if nothing moved, the platform’s clock is not running for your tenant. Either goes to BigLedger with the code and the date you expected. Then add to your month-end checklist: every clock’s Last Run Date is as recent as its timetable says. Nothing else will tell you when one stops.

Screen: Debtor Report applet, Historical Debtor Report, As of Date at the last month end

Reference: Scheduler — Troubleshooting

How the steps fit together

    flowchart TD
  s1["Step 1 — Decide what you are switching on, and who decided"]
  s2["Step 2 — Find the job in the picker"]
  s3["Step 3 — Create it inactive, with the properties it needs"]
  s4["Step 4 — Write the timetable"]
  s5["Step 5 — Rehearse with Run Now, or decide not to"]
  s6["Step 6 — Switch it on, and know when it first fires"]
  s7["Step 7 — Prove it fired, and keep proving it"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  s6 --> s7

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

1. You create a clock on a Monday with Status INACTIVE and a daily timetable at two in the morning, and switch it to ACTIVE on Wednesday afternoon. When does it first fire? At two on Thursday morning, the next time on the timetable
On the next tick after you save, because occurrences fell due while it was inactive
Never, until someone presses Run Now

2. Run Now shows its success message. What have you learned? The job finished without an error
The job was handed over; whether it worked shows only in the job's own results
The clock's Last Run Date has moved to now

3. Why do you create a new clock with Status INACTIVE? Only active rows are read, so nothing fires while you are still checking it
An active row cannot be edited after it is saved
Run Now only works on inactive rows

4. An active clock's Last Run Date never moves, although its timetable has passed several times and your other active clocks' dates keep moving. What is the likeliest cause? The job keeps failing inside, so the date is never stamped
The scheduler does not recognise the clock's code and passes over it without a word
The clock is waiting for somebody to press Run Now first

Answer key

On the next tick after you save, because occurrences fell due while it was inactive — Scheduler — Lifecycle and effects
The job was handed over; whether it worked shows only in the job's own results — Scheduler — Trying it safely before you need it
Only active rows are read, so nothing fires while you are still checking it — Scheduler — Trying it safely before you need it
The scheduler does not recognise the clock's code and passes over it without a word — Scheduler — Troubleshooting

This is a self-check. Your answers are marked in your browser and stay there — nothing is sent anywhere, nothing is recorded, and the marking is readable in the page source, so it is not a credential. Open the answer key at any time.

Back to the series · Play this as a presentation

Last updated on September 29, 2026

Add a clock, rehearse it, and prove it fired