Operations Scheduler

Every scheduled job in REDA Financials lives on one screen: the Admin Console's Operations tab — twelve cards, one per automation, each with its schedule, last outcome, pending-work counter and a Run Now. Configure the fleet once and the system runs its own nights. This is the map.

Opening the Operations tab

The scheduler doesn't live on any accounting record — it lives in the app's administration area. If you have never opened it before:

The Operations tab, as it opens. Every automated job in REDA Financials is one card here, and the badge on the right — Not Scheduled on all three above — tells you at a glance whether that job is running on a schedule. The chevron expands a card into its controls.

The twelve cards

Every card, verbatim

When you're standing in front of the screen, this is the reference to match against — each card's exact title, the description printed on it, the name its scheduled job runs under, and the run time the card suggests by default:

Two small notes on the job names: the four auto-apply jobs append your chosen batch size to the name you'll see in the job list, and the OCR loop stamps each cycle with a timestamp because it re-schedules itself every 15 minutes. Several cards also carry their own workload counters — Active Templates and Due Today on the recurring card, a Document Queue (Pending / Extracting / Errors) on the OCR card, an Active Currencies count on FX, and pending-work callouts such as "3 Purchase Invoices are pending auto-allocation and will be processed on the next run."

Anatomy of a card

• Status: Scheduled / Not Scheduled badge, Next Scheduled Run, Last Run and Outcome (Success / Partial Failure / Failed), a View Audit Log link to the receipts.
• Daily Schedule: a 24-hour Run Time (org time zone; the FX card runs on UTC) with Schedule / Reschedule / Unschedule.
• Manual Run: Run Now with a confirm — several cards add parameters (the recurring batch's Run Date for backfills, the auto-apply batch size) and pending-work counters ("5 Cash Receipts are flagged for auto-application and will be processed on the next run.").
• Safety rails everywhere: parallel runs refused, per-record/per-template/per-entity isolation, failures logged with CSV detail when numerous.

Scheduling a card, step by step

Every daily card schedules the same way. Using the Recurring Transactions Batch as the example:

Messages you may meet

The scheduler validates what you type and tells you plainly when something can't start:

The two odd ones out: the Start / Stop loops

Ten cards want a daily time. Two don't. The OCR Document Processing card is the first — documents arrive all day, so its batch runs as a self-repeating loop every 15 minutes, and the card swaps the time picker for three buttons whose on-screen descriptions explain themselves:

• Start — "Start the OCR processing loop. The batch will process pending documents and automatically reschedule itself every 15 minutes." Toast on success: "OCR Processing started. Job ID: 707xx0000067890".
• Stop — "Stop the OCR processing loop. Pending documents will remain in the queue until processing is restarted." A confirmation explains the consequence first: "This will stop the automatic OCR processing loop. Documents already being processed will complete, but no new cycles will start. You can restart at any time." Then: "OCR Processing has been stopped."
• Run Now — "Run a single batch cycle immediately to process pending documents without starting the continuous loop." Its modal, "Run OCR Processing Now", adds: "This will start a single batch cycle to process all pending and extracting documents. The batch will self-reschedule after completion."

The card's Document Queue counters show how much work is waiting — Pending, Extracting, and Errors — and the status reads Running now while a cycle executes. Try to start it twice and the card politely declines: "OCR Processing is already running." (or, on Run Now, "OCR Processing is already running. It will pick up pending records on the next cycle."). The loop itself is covered in depth in OCR by Email.

The E-Invoice Status Poll card is the second. It works the same way — Start, Stop, Run Now, no time to pick — and re-arms itself about every fifteen minutes while running. Each cycle transmits the Trails sitting at Queued and asks the authority for a verdict on those at Submitted, moving them to Accepted, Rejected or Error. On an org that files nothing electronically the card says so plainly ("No active e-invoicing setup exists yet") and can be ignored; where it does apply, nothing moves until somebody presses Start. The runbook is E-Invoice Status Poll.

FX Rate Sync: the multi-currency card

The FX Rate Sync card is the one card that can refuse to work at all: it needs Salesforce multi-currency, and when that isn't enabled the card disables itself with "Multi-currency is not enabled. FX rate sync is only available for multi-currency orgs." When multi-currency is on, three things distinguish it:

• It runs on UTC, not your org's time zone. Its schedule description: "Schedule the FX rate sync to run automatically once per day at the specified time (UTC)." The confirmation toast repeats it — "FX rate sync scheduled daily at 02:00 UTC."
• Run Now is called Sync Now. Description: "Trigger a one-time FX rate sync immediately. Rates are fetched and applied for today." The modal, "Sync Exchange Rates Now", spells out the effect: "This will fetch the latest exchange rates and update Dated Conversion Rates for all active currencies. The sync runs in the background." Then: "FX rate sync started. Job ID: 707xx0000024680. Check the audit log for results."
• Unscheduling warns about the consequence: "This will stop the daily FX rate sync. Rates will no longer be updated automatically. You can reschedule at any time." — followed by "FX rate sync schedule has been removed."

An Active Currencies count on the card shows how many currencies each sync will cover.

Every run leaves a receipt

Each batch writes a summary row to the Audit Log when it finishes — the record behind the card's Last Run and Last Run Outcome (Success / Partial Failure / Failed), one click away via View Audit Log. The summary states how many records were processed, succeeded, and failed; when individual rows fail on the recurring and auto-apply batches, a CSV file listing each failed row and its exact error is attached to that log entry. That CSV is your morning to-do list after a Partial Failure: open it, fix the causes, and either wait for tonight's run or click Run Now.

A Meridian morning

Meridian Properties Group runs all four regions from one org, so its controller starts each day on this screen. At 08:15 on July 2nd the sweep takes two minutes: the Recurring Transactions card shows Last Run Outcome Success and Due Today already back at a comfortable 0 — last night's 01:00 run generated the month's rent invoices. The aging, FX, and depreciation cards all report Success from their 02:00 wave. The Cash Receipt Auto-Apply card, though, shows Partial Failure: View Audit Log opens the run's summary, and the attached CSV names one receipt that couldn't apply because its invoice sits in a closed period. The controller fixes that one record, clicks Run Now with the default batch size, and the card goes green — no support ticket, no guesswork, because every card carries its own evidence.

Common mistakes to avoid

Where to go next

1. Operations Scheduler (Bulk Operations) — the admin-side companion.
2. Recurring Batch Scheduler — card #1 in depth.
3. The Admin Console — the tab's home.

Frequently asked questions