Salesforce Provider Compliance & Credentialing Automation Agent

Provider records in operational CRMs drift from the National Plan and Provider Enumeration System. Teams re-key NPIs, specialties, and status into Salesforce, then discover mismatches during enrollment, directory updates, or audit. The check is repetitive, source-specific, and easy to skip under backlog pressure.

An inactive or mismatched NPI is not a data-quality inconvenience. It blocks enrollment, contaminates directories, and creates compliance exposure. Catching it inside the system of record — before committee or payor submission — is the difference between a clean file and a rework cycle.

Analysts copied NPIs into NPPES, compared demographics and taxonomy by eye, and pasted notes back into Salesforce. There was no structured verification object, no recorded check date, and no consistent risk flag for the next reviewer.

• A Provider__c custom object as the system-of-record for verification fields: NPI status, specialty, API-check date, compliance notes, risk flag, confidence score, and screening source.
• An Apex service that called NPPES and returned normalized verification onto the record.
• A single-record Flow/action so an analyst could run the check without leaving Salesforce.
• Related verification data so the check was evidence, not a checkbox.

The Salesforce prototype established the pipeline that the later platform still uses: external source → adapter → normalized verification → fields an operator can act on. Einstein / AI concepts were considered only after deterministic verification — never as a substitute for the NPPES call.

Sources are labeled by access type. Restricted commercial or federal feeds are never presented as live credentials.

This version focused on verification and structured flags rather than a full readiness engine. Risk flags and confidence scores were recorded from the source check so a human still owned the operational decision. AI was not used to approve or deny credentialing.

NPPES lookup was live in the proof of concept. Broader compliance/enrollment architecture (entity types, committee tracking, sanctions, enrollment readiness) was designed around this prototype and then moved into the standalone platform for architectural flexibility. Restricted sources were never claimed as live.

• Salesforce custom object, Apex HTTP callout to NPPES, and Flow for single-record execution.
• Fields for specialty, API-check date, compliance notes, risk flag, confidence score, and screening source.
• Intentionally scoped as a working slice — one source, one record action — rather than a full credentialing suite.

Editorial workflow layouts — not screenshots of a claimed production product.

1. View 01

   Provider record with NPI verification fields populated from the live NPPES call.

2. View 02

   Flow action on a single record: run check → write status, specialty, timestamp, and notes.

3. View 03

   This is a CRM proof of concept, not a production credentialing product.

• A real NPPES call in Salesforce is enough to prove the source-adapter idea — and not enough to model PCs, groups, MSOs, and enrollment readiness.
• CRM automation is the right place to start if that is where operators already live; it is the wrong ceiling if the domain model needs to grow.
• Leaving the prototype in the story matters. Iteration is more credible than a clean-slate 'AI platform' that hides the first build.

• The standalone Provider Ops Platform is the continuation: same philosophy, broader domain model, public-source adapters, and explicit live/mock labeling.