Rescuing a Failed Salesforce Org for a Wealth Manager

This case study covers a Salesforce org rescue for a wealth management firm with three offices. A previous implementation had gone over budget and left the firm with a system its people no longer trusted. With an internal compliance audit approaching, the firm needed its client data back under control. Here is how we assessed the org, rebuilt it in 12 weeks and won users back.

Why the Firm Had Stopped Trusting Salesforce

Two years earlier, another consultancy had implemented Salesforce. By the time we were asked to help, the org had more than 60 active Apex classes, many firing on the same objects. Triggers competed with each other and changed data in ways nobody could predict.

The sharing model was the most serious issue. Advisers in one region could see client records belonging to advisers in another, which was a clear compliance problem for a regulated business. The system was also slow, and daily active users had fallen to about 34% of licensed seats.

Client contact details were being copied into Excel and edited there. The compliance team knew the Salesforce data would not stand up to scrutiny.

How We Assessed the Damage

We started with a two-week technical audit. For every Apex class, flow, sharing rule and profile we recorded what it was meant to do, what it actually did and whether it was still needed. The result was a prioritised plan with a risk rating for each item, which we took the leadership team through before changing anything.

This step matters in any rescue. Without it, you end up fixing symptoms while the underlying conflicts carry on. Our Salesforce health check follows the same approach on a smaller scale.

Rebuilding the Org in Three Phases

A security model that matches the business

We removed the existing profile and sharing configuration and started again. The new role hierarchy mirrors how the firm is actually managed. Sharing rules allow cross-region access only where it is permitted, and field-level security protects regulated financial data. Every change was documented for the auditors.

Automation that administrators can maintain

We retired 47 legacy Apex trigger classes and replaced them with record-triggered flows. Apex remained only where declarative tools genuinely could not meet the requirement. Any certified administrator can now read and change the automation without a developer.

Reporting built for compliance reviews

We built reports and dashboards around the questions that come up in quarterly compliance reviews. Field history tracking on key regulated fields shows when a value changed, what it changed from and who changed it.

Getting 200 People to Use It Again

Fixing the technology was the easier half. Persuading 200 people to trust a system they had written off took more care. Instead of click-by-click training, we ran 30-minute sessions with each team showing how the rebuilt org fixed the specific problems they had complained about. We brought printouts of the old error messages and showed what happened now instead.

Within three weeks, daily logins passed 60%. By week eight they reached 89%, and the sales manager reported that advisers were logging call notes without being asked.

How the Compliance Audit Went

The internal audit took place in week 14, two weeks after our engagement ended. It found no material issues with CRM data integrity. Audit preparation, which used to take three weeks of manual work, became a two-day review of system-generated reports.

Lessons for Firms With a Troubled Org

• Audit before you fix. A documented inventory stops you breaking something that looked unused.
• Treat the sharing model as a compliance control. In regulated firms, access design is not just an admin task.
• Prefer maintainable automation. Flow that your own admins understand lowers long-term cost.

Worried your own org has similar problems? Our article on reducing Salesforce technical debt is a good next read, or book a review with our team.