Schedules

Merchant Portal → Schedules (heading: Agent schedules).

Pick a Branch, then set one card per workflow — Cancel Rx and Refill Rx:

• enabled — whether this workflow runs at all
• Days — day-of-week chips (at least one; saving with none selected reports "Pick at least one day.")
• Start and End — the daily window
• interval — how often to check inside that window
• max docs and max runtime per run

Save shows Saved.

Agents pick this up automatically: on activation, every time the control window opens, on Start, on Refresh, and on every wake from sleep. The control window's Schedule row shows what is in effect. If the machine is offline the last-synced schedule stands.

What the schedule does — and does not — do

Important: In this build the schedule does not start the agent. No Windows scheduled task is registered, and nothing on the server can wake a stopped agent. A person clicks Start; the schedule governs what happens after that.

What it genuinely controls:

1. The wake cadence. Once running, the agent drains the queue and then sleeps until the next scheduled check — that is where ● Sleeping — next check Mon 08:00 comes from. Outside every window it sleeps to the next window's start (Friday 17:05 → Monday 08:00).
2. The offline-alert window. The watchdog only counts silence as "offline" while the schedule says the agent should be running — an agent that is off-shift is not offline. If a location has no schedule rows at all, it is treated as always expected, so alerting still works.
3. Which workflows are enabled. The portal is the source of truth: a workflow with an enabled row runs; one with no row, or a disabled row, does not. The agent's local list only applies when it has never synced.

Note: Disabling every workflow for a branch means the agent has no window to work in and will never process anything. That is the intended way to pause a location — but it will look like a broken agent if you forget you did it.

Editing schedules from the pharmacy PC

The agent's Settings → Worker Settings dialog has the same per-workflow fields. Prefer the portal: it applies to every machine at the location, survives a reinstall, and is what the offline watchdog reads.