Salesforce Org Health for Financial Services
Why compliance debt builds fastest, what it tends to look like, and the check for each pattern.
Financial services orgs tend to accumulate Salesforce debt faster than most because every compliance requirement becomes a permanent piece of configuration. Approval processes and validation rules get layered over years and are rarely retired, audit findings trigger permission changes that are never reversed, and integrations with core banking and compliance tools multiply. The same five findings tend to appear in a 3-to-10-year-old org: stacked approval logic, validation rules that contradict each other, permission sets that grew one audit at a time, integration users nobody owns, and automation nobody dares to touch. Each has a check you can run yourself. Running a free health check first gives you that picture before you put an agent on top of the org.
Why regulated orgs accumulate debt fastest
Financial services and compliance-software companies are hiring Salesforce admins, analysts, and platform leads. The job descriptions differ, but the underlying situation is usually the same: an org that has been running for several years, has been shaped by every audit and policy change in that time, and is now expected to support new work such as AI agents.
Three forces drive it. First, compliance requirements are additive: a control, once in place, is rarely removed, so approval processes and validation rules pile up. Second, audits create permission churn: access is tightened in response to a finding, and the history of why is lost when the admin who did it moves on. Third, integrations multiply: core banking, KYC, document, and monitoring tools each get connected by a different team, each with its own credentials. Debt in a regulated org is not carelessness. It is the byproduct of doing the careful thing repeatedly.
The 5 patterns that tend to show up
Approval processes stacked over years of policy changes
Symptom: Each new compliance requirement added an approval step or a parallel approval process. Old ones were deactivated in spirit but left active in practice, because nobody could prove a retired policy wasn't still being relied on by an auditor.
What it costs: Records stall in approval chains no current policy requires, approvers who left the company still hold pending items, and the people closing deals learn to route around the system instead of through it.
Check: List every active approval process per object, then compare each entry criteria and approver list against the current written policy. Anything nobody can tie to a live policy is a candidate for retirement.
Validation rules that contradict each other
Symptom: Rules were added one at a time, each correct when written, by different admins responding to different audit findings. Over time they overlap, and a record that satisfies one rule can be blocked by another.
What it costs: Users hit errors that no single rule explains, integrations fail on records that were valid when they were created, and bulk loads get blocked halfway. The workaround is usually a bypass flag, which quietly defeats the control the rule was meant to enforce.
Check: Export every active validation rule on your highest-volume objects and read them side by side. Look for overlapping conditions, hardcoded dates or user IDs, and any bypass condition that references a custom permission or a profile name.
Permission sets that grew one audit at a time
Symptom: Every audit finding produced a permission change: access removed here, a new restricted set added there. Removals were done carefully; the cleanup of what they replaced was not, so the old and new sets coexist.
What it costs: The org can no longer answer the simple audit question "who can see this field and why?" without a spreadsheet. Least-privilege is true on paper and unverifiable in the system, which is exactly the situation an examiner probes.
Check: Count permission sets and permission set groups, then flag any set with no assignments, any with a name that suggests a one-off request, and any user who holds overlapping sets that grant the same object access.
Integration sprawl around core banking and compliance tools
Symptom: Connections to core banking, KYC, document management, and compliance monitoring tools were built by different teams and vendors at different times. Some use integration users, some use named users' credentials, and some still authenticate with methods Salesforce is retiring.
What it costs: When one of those connections breaks or its owner leaves, nobody knows what depends on it. Failed syncs show up as stale customer data, and an over-privileged integration user is a finding waiting to happen.
Check: List every connected app and API-only user. For each one, confirm there is a named owner, a documented purpose, the minimum permissions it needs, and a recent successful login.
Automation nobody dares to change
Symptom: Flows, triggers, and legacy process automation enforce rules that auditors once signed off on. Because changing them might invalidate that sign-off, they are left alone, and new automation gets bolted on around them instead.
What it costs: Multiple automations fire on the same object in an order nobody has mapped. Release cycles slow down because every change needs a regression review, and the org's real behavior drifts from its documentation.
Check: For each core object, list every flow, trigger, and legacy automation that fires on it, noting trigger conditions and execution order. Any object with several unconditioned automations is where a change is most likely to cause a surprise.
A first step before an agent pilot
An agent acts on whatever the org already contains: the contradictory rules, the overlapping permissions, the unowned integrations. Seeing those first tells you what to fix before an agent inherits them. A Wrenk health check covers these categories without SOQL.
Permission sprawl
How many permission sets exist, which are unassigned or overlapping, and where access has accumulated beyond what a role needs — the audit-by-audit pattern from the third finding above.
Automation density per object
How many flows, triggers, and legacy automations fire on a single object, and whether they carry entry conditions, so you can see where a change is risky before you make it.
Integration users and connected apps
Every API-only user and connected app, when each last authenticated, and what it can reach, including the connections to core banking and compliance tools.
Validation and approval logic
Active validation rules and approval processes with the conditions that look obsolete, hardcoded, or bypassed, so cleanup can start with evidence rather than guesswork.
Deprecated auth flows
Connected apps still on legacy OAuth flows, or connections relying on the SOAP login() call Salesforce is retiring, both common on integrations set up years ago.
Related reading
- Wrenk for financial services — how Wrenk supports regulated Salesforce teams.
- Required field missing and validation rule errors — what to do when stacked validation rules block a save.
- 50-Point Salesforce Audit Checklist — the manual version of the checks on this page.
- Wrenk home
See what your org holds before an agent does
Answer a few questions about your setup and run a free health check — no account, no SOQL, no per-org fee.
Run Free Health Check