Skip to main content

Automatic scheduling

Automatic scheduling looks at the open positions in a schedule, weighs everyone eligible to fill them, and produces a proposal. Nothing is written to the schedule until you look at the proposal and click Apply. This is deliberate: the scheduler is a very fast, very patient assistant that has read every availability entry and every preference, but it is not the pastor, and it does not get the last word.

Before you begin

  • The schedule must be in Draft or Live state, and its positions must already be generated. See Building a schedule.
  • The more your volunteers have entered — availability, preferences, serving frequency — the better the proposal. A roster with no availability on file produces a mechanically fair schedule that ignores every real-life constraint.

Running a proposal

Automatic scheduling appears as Automatic scheduling on each schedule under Admin Dashboard → Ministry Scheduler → Schedules.

  1. Decide whether to turn on Also move positions a previous run filled. Leave it off the first time.
  2. Click Propose a schedule.
  3. Wait for the run to finish. It moves through Preparing, Queued, Starting, Running, and then Ready to review.
  4. Click Review on the finished run.

A run never touches the schedule while it is working, so you can leave the page and come back.

"Also move positions a previous run filled"

When this is on, the run may move assignments that a previous automatic run created, if doing so produces a better overall schedule.

It never touches anything else. Manual assignments, self-signups, standing arrangements, and team placements are left exactly where they are. Turn it on when you have run automatic scheduling once, then added more volunteers or availability, and want the whole picture reconsidered.

Reading the proposal

The proposal header reads Proposal: (filled) of (open) positions, and below it you get three things worth reading before you apply anything.

An automatic scheduling proposal, with the fairness comparison and the table of proposed assignments

The proposed assignments

A table of every assignment the run wants to make — the Date, the Volunteer, the position, and a Score. Expand a row to see Also considered: the other candidates the run weighed for that position and why it preferred the one it chose.

The fairness change

Fairness across the selected pools reports the total deviation from expected load before and after the proposal, and whether it improved by some amount or whether no improving move was available. It also tells you how many of the reassignments it evaluated were accepted.

Fairness in Sacramentum is not "everybody serves the same number of times." It is deviation from what each volunteer could reasonably be expected to serve, given the positions they were actually eligible for, their stated serving frequency, and their availability. Someone available one weekend a month is not under-served for serving once a month.

The positions it could not fill

Positions the run could not fill lists every gap, marking the Required ones. Each gap is explained with a funnel that shows the candidate pool shrinking layer by layer:

14 in the pool → after membership: 11 → after qualifications: 9 → after availability: 2 → after overlapping services: 0

The layers are membership, qualifications, availability, overlapping services, serving limits, household rules, and scheduling mode. Where relaxing one layer would help, the run says so: Relaxing serving limits would free 3 candidates.

tip

This funnel is the most useful thing in the whole feature and it is easy to scroll past. When a required position cannot be filled, the funnel tells you exactly which rule to look at — and often the answer is not "recruit more volunteers" but "the weekend cap is one lower than this roster can support."

Applying or discarding

  • Apply writes the proposed assignments to the schedule. Sacramentum reports how many were applied, and how many were skipped because the schedule had changed — someone filled a position by hand while the run was being reviewed.
  • Discard throws the proposal away. The schedule is untouched.
  • Retry runs it again, which is what you want after changing a rule, adding volunteers, or recording availability.
Two unfilled positions, each explained by a funnel showing the candidate pool shrinking layer by layer

You can review a proposal, discard it, change something, and run again as many times as you like. Nothing accumulates.

info

Reviewing and applying are separate permissions. A ministry leader may be granted Run auto-fill without Apply auto-fill proposals, in which case they see the proposal and the message You can review this proposal, but applying it needs the apply permission. See Leaders and access.

Run states

StateMeaning
PreparingGathering the positions, roster, and rules.
Queued / Starting / RunningWorking. Nothing is written yet.
Ready to reviewFinished. Open it with Review.
Applying / AppliedBeing written, or written.
DiscardedYou threw it away.
Out of dateThe schedule changed enough that the proposal no longer matches. Run a fresh one.
Failed / CancelledSee the message on the run.

When a run refuses

Some refusals are actionable, and the message says what to do:

MessageWhat to do
This proposal covers too many candidate combinationsSelect fewer roles or a shorter date range, then retry.
This proposal is too large to save safelySame — narrow the scope and retry.
The selected scope has too much history to evaluate safelyNarrow the scope, or shorten the fairness history window under Settings → Ministry Scheduling.
The fairness history window is longer than the scheduler supportsShorten it in Settings, then retry.
This schedule is closed or archivedReopen the schedule before retrying.
The proposal could not be preparedRetry once. If it fails again, contact support.

The size limits are real, not arbitrary: a whole year of every ministry at once is a very large problem, and the honest answer is to schedule a season at a time.

How to work with it well

  • Do the fixed placements first. Standing arrangements and teams should already be in place before you run a proposal, so the run is only solving what is genuinely open.
  • Collect availability before you run. A proposal built on an empty availability table will look fine and be wrong.
  • Read the unfilled list before the filled list. The assignments it made are usually unsurprising; the gaps are where you learn something.
  • Apply, then review the board. Automatic scheduling is a starting point, not a verdict. Adjust anything that a person would have done differently, and publish.

Troubleshooting

The proposal filled almost nothing

Look at the funnel on the unfilled positions. The layer where the pool collapses is your answer — most often availability (nobody has entered any, or too many people are away) or serving limits (a parish-wide cap that a small roster cannot satisfy).

It scheduled someone I did not expect

Expand their row and read Also considered. The run explains what it weighed. If the choice is genuinely wrong, the fix is usually a scheduling rule rather than a manual override — set their scheduling mode, record a preference, or add a pairing rule.

The same person keeps getting scheduled

Check whether their serving frequency preference asks for it, and check the Fairness and distribution report to see whether they really are over-served or simply the only eligible person. See Ministry reports.

A run says "Out of date"

The schedule changed after the proposal was built. Discard it and run a fresh one.

What's next