A scheduled workflow didn't run — or ran on everything
Find out why a scheduled workflow rule never fires (or fires on far too much), fix the date logic and reprocess window, and prove a successful run in the log.
Before you begin
- Access to workflow administration for the catalog or document type the rule belongs to
By the end of this guide you'll know why your scheduled rule fired on nothing (or on everything), have it matching only the documents you intend, and have proof of a successful run.
How a scheduled rule decides what to act on
A scheduled workflow rule is two separate decisions, and either one can be the problem:
| Decision | Controlled by | Failure looks like |
|---|---|---|
| When the rule runs | Process Interval: (Every Minute through Every Year, plus on Day / on Hour / on Minute for longer intervals) | Rule runs, but not when you expected |
| What matches at that moment | The trigger's field conditions | Rule runs on time but finds nothing — or finds everything |
"It didn't run" almost always means the rule did run — and matched zero documents.
Date conditions compare against the current date on the server running the workflow service, not your PC's clock. If the server's date or time zone differs from yours, "today" is the server's today.
Process Start: controls one extra behavior — On Workflow-Service Start also runs the trigger when the workflow service starts, while On First Interval waits for the first scheduled interval.
Step 1: Confirm the rule is enabled and the trigger logic
Open the rule where it's defined — global rules under Admin > Workflow, catalog rules under that catalog's Workflow area, document-type rules under the document type's Workflow area.
Confirm the Enabled checkbox is checked.
If Use Multiple Triggers is checked, look at Combine Method: — with
AND, every trigger must pass for the rule to fire; withOR, any single trigger firing is enough.noteOne impossible condition in
ANDmode silently blocks the whole rule, even when every other trigger matches.
Step 2: Check the date logic — the number one cause
For date fields, the Field-Match Type: dropdown offers: Equals (a literal date entered as YYYY-MM-DD in Field Value:), Equal to Current Date, Less Than or Equal to Current Date, Greater Than or Equal to Current Date, and two offset forms — Less Than or Equal to (Current Date Plus Offset Days) and Greater Than or Equal to (Current Date Plus Offset Days), each with an Offset Days (negative values allowed): input.
The trap: a relative-date condition only matches documents whose date lands exactly in that window on the day the run happens.
Work out, for the server's date today, which document dates your condition actually matches. A "remind me 14 days before the end date" rule matches only documents whose end date is 14 days out today — not "any document within 14 days," and never a document whose date is already past.
Check the documents you expected it to catch. If their dates don't fall in today's window, the rule ran correctly and matched nothing.
A test document with a date in the past can never fire a forward-looking rule — no matter how many intervals pass. This is the single most common "workflow is broken" report, and nothing is broken.
Step 3: Size the reprocess window — the "ran on everything" cause
Reprocess Matching Records After: (a number 0–999 plus a unit, default 1 Days) controls when a record that already matched becomes eligible to be evaluated — and actioned — again.
The engine evaluates candidates in batches of 100, finishing each batch before loading the next. So if your trigger's conditions match a huge historical set and the reprocess window keeps making those records eligible again, every run must chew through the entire backlog first. A five-minute rule can spend far longer than five minutes re-reading history and never reach the documents you actually care about — the run appears to do nothing.
Tighten the trigger's conditions so they only match the working window — the documents that could genuinely need the action now — instead of your whole archive.
Set the reprocess value so already-handled records don't keep re-entering that set every run.
What you should see: after narrowing, each run completes quickly and acts only on current documents.
Step 4: Test with one document that can actually match
Note the rule's Process Interval: so you know when the next run is due. For a faster test, temporarily set it to
Every 5 Minutes— and set it back afterward.
Create one new test document of the right type, with its date field engineered to match the next run — today's server date for
Equal to Current Date, or exactly the offset (for example, 14 days from today) for an offset condition.
Wait out the interval, then open the test document.
What you should see: the rule's action has happened — the field changed, the notification arrived, the document moved.
Success check: find the run in the log
Scheduled rule executions are logged to the Windows Event Log on the Content Central server — log ContentCentral, source AdmCCWorkflowSvc. If you don't have server access, ask whoever manages the server to check it; entries around the expected run time are the proof the rule executed.
While they're there, have them confirm the service Ademero Content Central Workflow Service is running in Windows Services — if it's stopped, no scheduled rule runs at all.
Admin > Workflow > Export History lists completed integration exports only. An empty Export History does not mean your rule didn't run.
Still stuck?
Contact support with this compact evidence bundle:
- The rule name and where it's defined (global, catalog, or document type)
- A screenshot of the trigger: Process Interval:, Field-Match Type:, any Offset Days, and Reprocess Matching Records After:
- The Combine Method: (
AND/OR) if the rule uses multiple triggers - Your test document's date field value and when you created it
- Windows Event Log entries from log
ContentCentral, sourceAdmCCWorkflowSvc, around the expected run time - Whether Ademero Content Central Workflow Service shows as Running