Salesforce or a custom system of record for a credentialing company?

Keep Salesforce if your credentialing workflow is mostly stages and tasks. Build a custom system of record when documents, verifications and expiration dates are the real work. Our custom systems of record start at $15,000, and many credentialing firms run both: Salesforce for clients and billing, a custom system for the credentialing file.

Salesforce is very good at accounts, contacts, opportunities, tasks and reports. A credentialing file is something else. It is a person with many credentials, and each credential has its own source, its own verification step, its own documents and its own expiration date.

You can model that in Salesforce with custom objects, Flows and a document add-on, and plenty of firms do. The question is how much admin and developer time it takes to keep that model working as your process changes. Three things decide it: how many credential types you track, how much of your intake arrives as documents, and whether your clients or providers need to log in and see their own status.

• Under roughly ten credential types, mostly structured data, internal users only: configured Salesforce is usually enough.
• Many credential types, heavy document intake, a client-facing portal: Salesforce starts to bend, and a custom system of record (or a custom layer on top of Salesforce) gets cheaper over time.
• Somewhere in between: keep Salesforce as the system for clients and revenue, and build only the credentialing file outside it.

The Salesforce licence figures below are general market list prices, which vary by edition and contract. The custom figures are Smplfy’s own.

Per-seat cost matters more than people expect. Credentialing coordinators, reviewers and part-time verifiers all need access, and a custom system does not charge per seat. The trade is that you now own software and need someone to look after it.

The pattern we see most is Salesforce kept for sales, client accounts and invoicing, with a custom system holding the credentialing file. Here is the flow for a new provider application:

1. A client signs, and the Salesforce opportunity moves to Closed Won. A webhook or scheduled job creates a matching client record in the credentialing system, keyed on the Salesforce Account ID so it can never be created twice.
2. The client gets a portal login and uploads licences, certificates and IDs straight to the provider’s file instead of emailing them.
3. Each credential gets a verification task with an owner, a due date and the source it must be checked against. Expiration dates are stored as data, not in a note field, so a renewal queue builds itself.
4. When a file changes status, the system writes the status and percent complete back to a few fields on the Salesforce Account. Sales and account managers see progress without anyone opening a second tool.
5. Every status change is logged with who made it and when, so you can show an auditor how a file was approved.

This is close to the work we do for nCred, a credentialing company: ongoing development of a client portal with Salesforce-connected dashboards, self-serve document uploads and streamlined AWS deployments. Salesforce stayed. The parts it was bad at moved next to it.

• API limits. Salesforce caps API calls per org every 24 hours. A sync that polls every minute for every record will hit that cap. Use change events or batched queries.
• File storage. Salesforce file storage is limited by edition, and extra storage is expensive. A credentialing firm storing thousands of PDFs a month runs into this early. Many teams keep files in S3 or similar and store only the link in Salesforce.
• Duplicate people. The same provider applies through two clients, or under a maiden name. Pick one stable identifier (a licence or registry number, for example) and match on it before creating anything.
• Documents before the record. A provider uploads a licence before the application exists. The system has to park the file and attach it later, or it gets lost.
• Upstream field changes. An admin renames or deletes a Salesforce field and the sync quietly stops writing. Alerts on failed writes catch this within hours instead of at month-end.
• Expired tokens. Integration users get deactivated or lose permissions. Run integrations under a dedicated integration user and alert on authentication failures.

Take a credentialing firm with 25 internal staff, 12 credential types and a few hundred active provider files. They are on Salesforce, and intake comes in by email.

These are illustrations, not quotes. The range moves with the number of credential types, how messy the existing Salesforce data is, and whether any document reading is automated. We price real work as a fixed scope after a call.

Stay on Salesforce if your team is small, credential types are few, intake is mostly structured, and a capable admin already keeps it tidy. Spend money on cleanup, not a rebuild.

Go hybrid if Salesforce works for sales and accounts but coordinators live in spreadsheets and inboxes to track verifications and renewals. This is the most common answer for credentialing firms.

Go fully custom only if Salesforce barely does anything for you beyond holding the files, and per-seat licences are a meaningful line item. Hire no one yet if you cannot write down your verification steps for each credential type. Do that first. It is the spec any build will need.

Can Salesforce handle credentialing on its own?
Yes, for simpler workflows. With custom objects for credentials, Flows for tasks and a document add-on, Salesforce can track applications, verifications and expirations. It gets harder to maintain once you have many credential types, heavy document intake or a client-facing portal.

How much does a custom credentialing system of record cost?
At Smplfy, custom systems of record start at $15,000, and the price rises with credential types, integrations and portal features. A smaller step, such as a client upload portal connected to Salesforce, can start around $4,000. We bill $85 an hour, or a fixed price after scoping.

Do we have to give up Salesforce to build a custom system?
No. Most credentialing firms keep Salesforce for sales, accounts and billing, and move only the credentialing file into a custom system. A sync keeps the status fields in Salesforce current, so account managers do not need a second tool.

How long does it take to build a custom credentialing system?
A Salesforce-connected portal or intake tool typically takes two to four weeks. A hybrid credentialing system with verification queues, expiration tracking and two-way sync usually takes two to three months. Messy existing data and unclear verification rules are what stretch timelines.

What goes wrong most often with Salesforce integrations?
Hitting the daily API limit, renamed or deleted fields that silently break a sync, deactivated integration users, and duplicate records for the same person. Each one can be designed around: batched or event-driven sync, failure alerts, a dedicated integration user and a stable matching key.

We’ll send a free written scope or do a 20-minute call. Have ready your Salesforce edition and user count, your credential types, roughly how many active files you hold, and which steps run in spreadsheets or email today. Start a conversation.