For nearly 15 years, Salesforce has been the engine room for our customer data here at FreeAgent. Since we first brought it on board in 2011, it has grown from a straightforward CRM into a complex, deeply integrated platform. While one blog post cannot cover every detail, we hope this gives you a better understanding of how we leverage Salesforce and the engineering approach we use to maximise its impact.

The Salesforce Data Model

If you are new to Salesforce, the easiest way to think of its structure is as a relational database with pre-configured tables, which it calls ‘objects’. The standard Salesforce data model is vast, but our core processes primarily leverage a few of its most important standard objects: Leads, Contacts, and Accounts. These directly represent the customer lifecycle.

• Lead: This is where potential customer data is stored. A lead could be created when someone requests a trial, downloads a report from our website, or registers for one of our events.
• Contact & Account: Account represents an organisation which, in turn, holds multiple Contact records. A crucial step happens during “Lead Conversion,” where a qualified Lead is transformed into a Contact linked to an Account. This creates a normalised one to many (Account to Contact) relationship, fundamental for managing B2B (business-to-business)  interactions.

Beyond the standard model, we also utilise custom objects to meet specific needs. We use these kinds of objects to store data from the FreeAgent app, which we may share more about here in the future. 

Clicks vs. Code: Our Automation Approach

To manage our processes, we rely on a dual approach to automation, favouring no-code tools for their maintainability and speed, and reserving custom code for unique business requirements.

Our primary tool is Salesforce Flow, the platform’s modern declarative builder. From an engineering perspective, this “clicks-not-code” approach means faster development cycles and lower maintenance overhead. Another way to build automation is through Apex. This is a proprietary coding language developed by Salesforce, with a syntax that will feel very familiar to Java developers as it resembles a streamlined version of an earlier iteration of the language.

We use Apex sparingly to develop complex logic that is difficult to implement in Flow. For example, we maintain a small function that reformats mobile numbers to ensure data consistency. This minimalist and targeted approach to code keeps our system agile and highly maintainable.

An Integrated Ecosystem

Our website is the most significant data hub integrated with Salesforce, but our instance is plumbed into a variety of other tools, each representing a key business process. This includes call-booking platforms, e-signature solutions for agreements, and of course, the FreeAgent app itself, which feeds data back for analysis.

For the most part, these integrations follow a standard ingestion pattern to link every interaction to a single profile. For example, when a person registers for a webinar on our website, the logic first looks up their email address within existing Contacts (presenting a customer), then Leads (or a potential customer). If a record already exists, we use it to match the new event registration. If not, we create a new lead record and then match the registration data to it. Our purpose is to forge a holistic customer experience, ensuring we understand each person’s journey and can maximise our product’s impact. 

Navigating the Challenges of a Mature Platform

Building and maintaining a platform on this scale for over a decade is incredibly rewarding and comes with interesting, ongoing engineering challenges. Two key areas that require our continuous focus are managing our automations at scale and evolving our data model.

The first challenge comes from the scale of our automation. Our extensive use of Salesforce Flow means we have a vast library of active automations. That means one of the essential tasks at this scale is managing their execution order. A single record update can trigger numerous flows, and ensuring they fire in the correct sequence without creating conflicts or race conditions requires rigorous architectural planning and a deep understanding of the Salesforce transaction model.

The second challenge arises from our integrated ecosystem. Our Salesforce instance connects to numerous third-party platforms for processes like call booking, email automation and more. Each of these tools introduces its own operational logic. The engineering challenge here is to manage the downstream impact on our both external and internal automations. This requires a holistic approach to architecture, ensuring external event trigger and workflows interact predictably with our existing automations in Salesforce to prevent conflicts and maintain data integrity across the ecosystem.

In a system that has been active for over a decade, we need to proactively enhance our data model to support new business initiatives while also diligently curating our existing assets. On one hand, we are constantly adding new fields or automating data capture to support evolving processes. On the other hand, we also run a continuous process of identifying and safely decommissioning legacy assets, like unused data fields and outdated reports, that may no longer be in use. Using agile methodologies, we have the flexibility to prioritise enhancements and technical debt. This approach enables our platform to evolve effectively while remaining reliable and performant. 

Conclusion

As you can see, our Salesforce instance is far more than a CRM; it’s a complex and powerful engineering platform at the core of FreeAgent’s operations. It represents a constant, engaging balance between maintaining a robust data architecture, leveraging powerful automation, and pragmatically evolving a mature system. 

We hope this has given you a clearer look under the hood and an insight into the engineering that powers FreeAgent.