Quick answer
OnBase DIP stops importing documents for one of five reasons: the scheduled process never ran, the workstation running it isn’t registered or licensed for the Document Import Processor, the index file doesn’t match the DIP format, the source files were unreachable or not ready when the schedule fired, or the documents imported and the batches were never committed. Start in two places — the Windows service that runs the schedule, and the Awaiting Commit queue — then work the causes in order below.
01 — What You’re Seeing
The files are in the folder. The documents aren’t in OnBase.
Confirm you’re on the right page before you touch anything.
One or more of these signatures, on an estate where a Document Import Processor (DIP) job normally runs:
- Last night’s drop — document files plus index file — is still sitting in the source folder, untouched, and no new batch appears under Processing | DIP.
- Batches exist but the documents aren’t retrievable — the import ran and everything is parked in Awaiting Commit.
- The verification report is full of errors — Hyland’s report buckets them as errors concerning keywords, errors in indexing documents, errors concerning file type, and an inaccurate number of documents and pages.
- A DIP that ran nightly for years stopped after a patch window, a password rotation, or a server move — and a manual run from the Thick Client still works fine.
- The index file is gone and nobody can say what was in it — by default, OnBase deletes the import index file after processing.
None of this errors loudly. DIP is batch plumbing: when it fails, it fails by absence — no batch, no alert, no ticket until a department asks where Tuesday’s invoices went. It’s the same silent-failure family as Workflow timers that stop firing: the platform stays green while the work stops moving. (The full set of what Reveille checks on this platform is in the Reveille for Hyland OnBase technical overview.)
02 — Causes, Ranked by Likelihood
Five causes account for nearly every case
Confirm before you fix — each cause has a cheap, specific test.
| # | Cause | How to confirm | Fix, in short |
|---|---|---|---|
| 1 | The scheduled process never ran — the service behind it is stopped or misconfigured | No new batches since a specific date. In services.msc the Thick Client service is stopped, failing, or was never restarted after a config change. | Fix the service, its arguments, and its account; restart it after every configuration change. |
| 2 | Registration or licensing — the machine can’t run DIP at all | Workstation Registration doesn’t show Document Import Processor on the processing machine; no DIP license, or the service account never logged in through a client. | Register the workstation, assign the license, log the account in once interactively. |
| 3 | Index file doesn’t match the format — documents error instead of importing | Verification report shows keyword, indexing, or file-type errors, or the document and page counts are wrong. | Fix the index file or the DIP format — delimiters, field order, tag names — and re-run. |
| 4 | Source files unreachable or not ready — the run fires into an empty or locked folder | The process ran (status queues show it) but found nothing; share permissions changed, or files arrive after the schedule fires. | Restore access for the service account; align the schedule and preconditions with the file drop. |
| 5 | Imported, never committed — the batches are parked | Processing | DIP shows the batches under Awaiting Commit; there is no scheduled commit, or it runs before the import finishes. | Commit the parked batches; schedule the commit after the import window. |
Cause 1 deserves its billing. A scheduled DIP is a Windows service wrapping the Thick Client, which means it inherits every classic service fragility — and Naviant’s DIP best-practices guide adds that most DIP problems trace back to configuration, with the index file format the most common offender after that.
03 — The Fixes
Work them in repair order
Reading the evidence first beats restarting things at random.
1. Establish what actually ran
In the Thick Client, open Processing | DIP. The DIP Queue window lists each format, its process jobs, and the status queues — that tells you in one look whether last night’s run produced a batch, produced an errored batch, or produced nothing. Nothing at all means cause 1 or 2; errored items mean cause 3; batches in Awaiting Commit mean cause 5.
2. Fix the service that runs the schedule
Scheduled DIP processing runs through a Windows service created from the Thick Client (the executable is obclnt32.exe with arguments naming the ODBC source and the -SCHED switch). Per CU Boulder’s OnBase admin guide — the most complete public write-up of this mechanism — the recurring failure points are: the service isn’t running or isn’t set to Automatic; the service account lost the Log on as a Service right; a rotated password that was never re-entered through an interactive client logon first; wrong environment name or mangled quotation marks in the service arguments; a configuration change made since the service last restarted; and a Processing Workstation on the schedule that doesn’t match the machine the service actually runs on. Check each, restart the service, and watch one cycle complete.
3. Verify registration and licensing
On the processing machine, open the Thick Client and go to Admin | User Management | Workstation Registration. The current machine is marked with an asterisk — confirm Document Import Processor is registered for it. Naviant calls this the step everyone forgets on first install, and DIP will not run without it. Then confirm a DIP license is available and that the account has logged in to OnBase from that workstation at least once.
4. Read the verification report before re-running
When documents error rather than vanish, the verification report says why, in four buckets: keyword errors, indexing errors, file-type errors, and count mismatches. Almost all of them are index-file formatting — field order that doesn’t match the configured keywords, missing delimiters, tags over 20 characters, or an index that references files that aren’t in the folder. Fix the format or the file, not the symptom. Two defensive settings while you’re in there: configure a backup path (Naviant and Hyland both strongly recommend it), because by default OnBase deletes the import index file after processing — which makes re-running a failed import archaeology instead of a retry. Setting the index file read-only preserves it for a single run.
5. Commit what imported
Import and commit are separate steps, and a batch in Awaiting Commit is not done — commit it manually, or schedule the commit (right-click the DIP format, Schedule Commit) for a time safely after the import window closes. While you’re there, check the format’s Workflow option: pushing documents to Workflow during processing instead of on commit is community-flagged as the setting that quietly breaks scheduled management of those documents later.
04 — How to Stop It Recurring
DIP fails by absence. Watch for the absence.
Every cause above has the same tell: nothing turns red.
The service stays listed, the share stays mounted, the platform reports healthy — and the only true signals are operational ones: no committed batch since yesterday, uncommitted batches climbing, the source folder count not going to zero. Platform SLA is not workflow SLA, and “the documents made it in” is a workflow SLA. Those signals have to be watched continuously, because no one opens the DIP Queue window on a day nothing seems wrong.
To be precise about coverage: Reveille has no test that reads your DIP format or parses your index files — that configuration is yours. What it watches, out of the box, is every link in the chain a DIP job depends on: Check OnBase Services for the service that runs the schedule, Uncommitted Batches and Committed Batches for imports that ran but parked, Check Disk Groups, Disk Group Locks, Batch Locks, and Process Locks for the commit path, OnBase License Usage for cause 2, and connectivity checks for the OnBase File Server and Database Server underneath it all.
Reveille for Hyland OnBase
As the only agentless monitoring system to integrate with OnBase, Reveille for Hyland OnBase comes pre-configured with over 80 OnBase-specific tests and over 85 OnBase dashboard metrics — including the batch, commit, lock, and service checks above — for OnBase 18 and above. See Reveille for Hyland OnBase →
Supporting client estates as an MSP, SI, or ISV? That’s what Reveille SENTRY is built for — multi-tenant observability for the estates you manage.
Before the next import parks overnight
See the 80+ OnBase tests run against a live environment.
Enter a business email and the platform you run. The demo environment opens with the Uncommitted Batches, Committed Batches, and OnBase Services checks already configured.
No credit card · Nothing to install · Runs on Reveille’s sample estate. Want the list first? Read the OnBase technical overview.
Quick answers
