Skip to main content
Operations → Scheduled Tasks → /schedules Much of what the platform does happens without anyone clicking anything: recurring invoices are generated, payments are allocated, meters are polled, penalties are assessed, collections cases are swept, statements are produced. Scheduled Tasks is where you see all of it.

​
What a schedule record holds

Recurrence rule and anchor together define when the job runs — the anchor is the reference point the recurrence counts from, which is why two jobs with the same cadence can run at different times.

​
Actions

Execute now on a money-touching job — invoice generation, allocation, penalties — does real work immediately. Confirm the branch and the period before you run it, and check whether the job has already run for that period.

​
Execution history

Each schedule keeps its execution history: when it ran, how long it took, whether it succeeded, and the result or error. This is the first place to look when something that should have happened did not.
1

Check the last status

Success, failure, or never run.
2

Check the next run

A next-run date in the past means the schedule is paused or the scheduler is off.
3

Read the error

Failures record the reason, not just the fact.
4

Check duration trends

A job whose duration is growing steadily will eventually not finish inside its window.

​
How jobs are enabled

Scheduled work sits behind two switches:
  1. A master scheduler switch for the environment. It defaults to off outside production, so a non-production environment cannot write real invoices or payments against live data.
  2. A per-job switch. New jobs are individually gated and default to off, so a module can ship fully built and stay dormant until an organisation is ready for it.
Both must be on for a job to run. If a job appears configured but nothing happens, check both before investigating the job itself.
Engines that touch money or reach residents also run in shadow mode first — computing and staging actions for a human to confirm. Enabling the job is not the same as authorising it to act alone. See Collections overview.

​
Fairness across organisations

Jobs that sweep large populations work organisation by organisation in rotation, with per-branch limits, rather than taking a single global batch. Without this, one large branch can consume an entire run and every other branch is starved — a failure mode that looks exactly like “the job did nothing”. If a job reports work done but a particular branch never seems to be processed, this is the first thing to check.

​
Jobs worth knowing

​
Approval on schedules

Some schedules carry an approval state, so a job with material effect can require sign-off before it becomes active. The approval request, approver and approval time are recorded on the schedule.

​
Common problems