We started with a full health-check across their Salesforce org, going through automation, integrations, and the slowest-running reports to figure out what was genuinely causing the drag versus what just felt slow because everyone had normalized it over time.

A good chunk of the early work turned out to be more archaeology than engineering. Some of the old automation referenced fields that had been deprecated years back and were quietly failing in the background without throwing an error anyone would notice. We had to trace each one back to understand what it was originally meant to do before deciding whether to fix it, replace it, or just retire it.

From there, our ongoing work included:

• Rebuilding a few of the slowest reports using more efficient queries, which brought load time down noticeably on the ones staff pulled up daily
• Doing targeted Apex development to replace some of the more fragile old automation with cleaner, documented logic the client’s own team could actually understand going forward
• Reviewing and tightening a Salesforce integration with their patient records system, which had a few loose permission settings nobody had caught until now
• Setting up a recurring monthly cadence, a proper health-check, a look at any new Salesforce releases that might affect their setup, and a basic security review, instead of leaving things until something forced attention

One thing that came up early and mattered more than we expected: documentation, or the lack of it. A lot of the original Salesforce automation had none, so every fix took longer than it should have just to understand what we were actually looking at. Part of our ongoing work now includes documenting things properly as we touch them, so whoever works on this system next- us or someone in-house down the line  isn’t starting from zero.