Connecting outreach software to OpenDental: the implementation guide

An OpenDental integration implementation is a short, ordered project: put one name on it, enable the vendor's customer key in OpenDental, confirm what that key is allowed to do, check the first lists against reports the office already trusts, watch the first write-backs land in the commlog, and only then make the tool part of the morning routine. Run in that order, the work is measured in days. Run in no particular order, the same connection produces a tool the team quietly stops opening, because the first time the list looked wrong nobody could say why, and a list nobody trusts is a list nobody works.

This is the implementation half of a pair. The evaluation half, our guide to the OpenDental API and what integrations actually connect, covers the mechanics of access: the two keys, the permission groups, and the questions that belong in the contract before you sign. This page assumes the vendor is chosen and the contract already states, resource by resource, what the tool reads and writes. It starts at the moment someone hands your office a customer key, and it applies the same way to a single office and to a group rolling out one location at a time.

Who owns the implementation?

Three roles, and each phase below belongs to exactly one of them. In a small office two of the three are the same person, which is fine. The failure mode is not overlap; it is a phase with a department's name on it instead of a person's.

• The implementation owner. The office manager or operations lead. Sets the dates, makes the calls the checklist forces, and signs off on go-live.
• The OpenDental admin. Whoever administers your OpenDental. Enables the key, reads its permissions, and confirms the eConnector is running if the vendor connects remotely.
• The daily user. The scheduling coordinator or front desk lead who will work the list. They run the validation spot checks, because they are the person who has to believe the answers.

In a group, add a fourth: one group-level owner who runs the rollout, with a named contact in each office. What does not work is a vendor-led implementation with no internal name on it. The vendor can flip every switch and still cannot make your Tuesday morning use the tool.

The implementation, phase by phase

Seven phases, each with an owner and a condition that means done. Print the table, put real names in the owner column, and date each row. The table is the whole method; the sections after it expand the phases where implementations actually stall.

Phase 2: enable the key, and note where the off switch is

The admin pastes the customer key into Setup, then Advanced Setup, then API, and checks Enabled. The same window shows what the key is allowed to do, and the checkbox that turns access on is the one that turns it off; write both facts into the office's operations doc while the window is open. If the vendor connects remotely, requests ride the eConnector, the service already running for OpenDental's eServices, so "the integration is down" and "the eConnector stopped" are usually the same event with the same fix.

Phase 3: what should you validate before trusting the daily list?

Validate against reports the office already trusts, not against the vendor's demo. Four spot checks, all doable inside an hour:

• The count check. Patients due this month on the tool's list, against the OpenDental Recall List with matching filters. The totals will not match to the digit; every gap should have a reason.
• The name check. Pick five patients the front desk knows well and confirm each one's status, balance, and last visit look right.
• The exclusion check. Find one patient who must never be called, and confirm they are absent from the list.
• The freshness check. Book a patient off the list today, and confirm they are gone from tomorrow's list.

Most discrepancies are the database, not the connection: recall intervals still at their defaults, appointment statuses each hygienist uses differently, treatment plans nobody closed out. An integration reads what is there. Our walkthroughs of the OpenDental recall list and the Treatment Finder report cover the setup behind the two lists that matter most, and fixing that setup is worth doing whether or not an integration ever ships.

Phase 4: watch the first writes land

An outreach tool's writes should be narrow and visible: a commlog entry for each attempt, perhaps a confirmation or recall status. Have the daily user log five outcomes, then have the admin open those five charts and find the entries: right patient, right date, right communication type, the staff note intact. Do this in the first week, while five is the total and checking every one is cheap. A write problem found at five entries is a support ticket; found at five hundred, it is a cleanup project.

The connection is the easy part. The deliverable is trust: the first morning the front desk works the list without checking it against a report first, the implementation is over.

How long does an OpenDental integration take?

The connection itself is fast; the calendar time is paperwork and habit. For MyDentalForce, a new office is typically live within days of getting access. When an implementation drags into weeks, the connection is rarely the long pole. What actually stretches it: a contract waiting on a signature, an eConnector nobody restarted, a recall setup that needs cleanup before the list means anything, and a front desk that first heard about the tool on the morning it went live. All four are avoidable, and three of them are avoidable before the key even exists.

The first list is an audit of your own data

Plan for the first ranked list to be a little embarrassing, because it reads the database as it is, not as everyone assumed it was. Expect lapsed patients still marked active, recall types nobody assigned, and treatment planned years ago that was completed elsewhere or declined without anyone updating the chart. That is not the integration failing. That is the integration doing its job on data that had no daily reader until now.

Two rules keep the cleanup sane. First, fix records in OpenDental, the system of record, so every tool downstream inherits the correction. Second, give cleanup to the daily user in bounded doses, twenty minutes a day inside the phase 6 rhythm; a clean-the-whole-database-first project postpones go-live indefinitely. The plainest definitions of who belongs on which list are in our glossary entries on hygiene recall and unscheduled treatment.

Going live across more than one office

A single office runs the seven phases in order, and one week end to end is a normal pace. A group runs them as a pilot plus a template. Pick one office, ideally the one with the strongest daily user rather than the biggest schedule, run all seven phases there, and write down every surprise. Then repeat per office. Each office gets its own key enablement, its own validation pass, and its own five-day rhythm, because each office's database has its own history.

Two things change at group scale. Access has to be scoped on purpose: in MyDentalForce, role-based access is scoped per role and per office, so a scheduling coordinator sees their office's list, a regional manager sees several, and nobody audits access from memory. And the review phase becomes the manager's habit rather than a meeting: managers see per-office activity and results without asking, which is what makes office five's stalled rollout visible in week one instead of quarter two. Our FAQ covers what MyDentalForce connects to today.

What this looks like in MyDentalForce

The phases above are vendor-neutral; here is how they land with us. MyDentalForce integrates with OpenDental today. Once an office's key is enabled, it builds one ranked daily call list for that office from the office's own OpenDental data: due and overdue hygiene recall, unscheduled treatment, and lapsed patients, rebuilt every morning. Every call outcome is logged and written back to the practice management system, which is exactly what phase 4 checks. Patient Outreach is the daily list itself, and Roles, Security and Controls is where the phase 5 scoping lives. A new office is typically live within days of getting access, and the same engine runs the daily operations of a 19-office group in Houston.

Print the phase table, put a name and a date on every row, and start the paperwork this week; the key is the fast part. If the vendor you are implementing is us, book a walkthrough and we will run the first validation pass with you, on your own OpenDental data.