FSC Org Health Audit: How to Assess Your Salesforce FSC Implementation

An FSC org health audit is not a Salesforce health check. Salesforce's own health check tool scores your security configuration — password policies, session settings, remote site settings. Useful, but it tells you nothing about whether your Financial Services Cloud implementation is actually working for your advisors and your business.

A proper FSC org health audit answers four questions: What are you paying for that you're not using? What are you maintaining that you don't need? What is silently broken? What is it costing you?

Before You Start: Access and Scope

You need System Administrator access to the production org. Not a sandbox — production. Many issues only appear in production because the data volume, user behavior, and integration traffic are different from any sandbox environment.

Document the scope before starting:

• What FSC licenses does the org have? (Full FSC, FSC with OmniStudio, Einstein Relationship Insights, etc.)
• How many active users? What profiles are in use?
• What core banking integrations exist?
• When did the org go live? Any major releases since then?
• What are the top 3 complaints from advisors and admins?

Phase 1: Metadata Analysis

Pull the org's metadata using Salesforce CLI (sf project retrieve) or the Metadata API. You're looking for:

Apex Code Volume and Complexity

Count active Apex classes and triggers. For each trigger, document: which object it fires on, which DML operations it handles, whether it has a bypass mechanism, and its test coverage percentage. Any trigger below 85% coverage is a risk. Any trigger on FinancialAccount, Account, or Financial Holdings without a bypass is a governance risk — you can't disable it without a deployment.

Custom Object Census

List every custom object in the org. For each, identify: record count, last modified date, which profiles have access, and whether it has a functional equivalent in FSC native. Any custom object that duplicates a native FSC object (Referral__c vs. Referral, Client_Activity__c vs. Interaction Summary) is a remediation candidate.

FSC Feature Utilization

This is the core of the audit. For each major FSC feature, check whether it is: licensed, installed, configured, and actively used.

'Licensed but not configured' is a direct cost line: you're paying for the license with no return. 'Configured but not in use' is an adoption failure. Both have different remediation paths.

Phase 2: Sharing Model Review

The sharing model review is where most audits find critical issues. Start with the org-wide defaults (OWD) for Account, Financial Account, and Financial Holdings. Then map the sharing rules:

• How is advisor-to-client access granted? Is it via the FSC relationship sharing engine (correct) or manual sharing/custom Apex (risk)?
• What is the branch access model? Can Branch Manager at Branch A see clients of Advisor X at Branch B?
• How does household visibility work? If Advisor A owns the husband and Advisor B owns the wife, can each see the other's client's financial accounts?
• Are there any 'Public Read/Write' OWDs on sensitive objects? (Surprisingly common in orgs that 'fixed' sharing problems at go-live and never revisited.)
• Is the Financial Services Cloud managed package sharing rule set active and correctly configured?

Phase 3: Integration Health Check

For each integration (core banking, document management, email, telephony), check:

• Error rate: what percentage of integration calls fail? A rate above 0.5% warrants investigation.
• Error handling: when integration calls fail, does Salesforce know? Are errors logged and routed to someone who acts on them?
• Data freshness: for real-time integrations, what is the p95 latency? Are advisors seeing stale balance data because the integration is slow?
• Schema drift: has the source system schema changed since the integration was built? Core banking upgrades often cause silent schema changes that corrupt data.
• Bulk load performance: how long does the nightly batch sync take? Any job taking over 4 hours is at risk of hitting governor limits during peak usage.

Phase 4: User Adoption Analysis

Pull login and activity data from the Salesforce Setup Audit Trail and User login history. You're looking for:

• What percentage of licensed users logged in at least once in the past 30 days? Below 70% suggests adoption issues.
• Which objects are advisors actually creating and editing? If Financial Account records are rarely modified, advisors aren't keeping them current.
• Are Interaction Summaries being created? If the ratio of Interaction Summaries to Active Users is below 5 per month per advisor, the feature is not being used.
• What is the Referral creation rate? Compare to business expectations.
• What are the top search terms in Salesforce Global Search? This tells you what advisors are actually trying to find.

Scoring and Presentation

An FSC org health audit needs to produce a score that a CXO can understand in 10 minutes — not a 200-page technical document.

We use a four-dimension score, each out of 100:

• OOB Utilization (0–100): percentage of licensed FSC features that are both configured and actively used. A score of 30 means you're using 30% of what you're paying for.
• Technical Debt (0–100): inverse of customization complexity. 100 = clean, maintainable, well-tested. 40 = significant custom code with fragile dependencies.
• Sharing Model Health (0–100): based on whether access controls follow best practice, absence of public OWDs on sensitive objects, and sharing rule complexity.
• Integration Quality (0–100): based on error rates, data freshness, schema alignment, and error handling maturity.

Each dimension score gets a one-sentence finding and a one-sentence recommendation. The CXO deliverable is a single page: four scores, four findings, four recommendations, and a prioritized remediation roadmap. Everything else goes in the appendix.

The ROI Bleed Calculation

The finding CXOs respond to most is a concrete number: what is the unused FSC capability costing you annually? This calculation has two components:

• License cost for unused features: if Einstein Relationship Insights is licensed and unused, what is the per-seat annual cost × active users? This is direct, recoverable cost — you could downgrade the license.
• Productivity cost of poor adoption: if advisors are using spreadsheets alongside Salesforce, or calling back-office for data that should be in the CRM, estimate the time cost. Even a conservative 30 minutes per advisor per day × average advisor cost = a significant annual number.

Present this number as 'annual value at risk' rather than 'money wasted.' It's more accurate and more actionable — it frames the remediation investment as recovery, not cost.