Understanding Salesforce architecture: mastering organizational complexity

Understanding the core of Salesforce architecture

Over 25 years ago, Salesforce.com changed the industry for business software applications, releasing a platform that could be used out-of-the-box and with no IT skills required to start up and use. Using a secure multi-tenanted platform built on tried-and-tested technology, with a unique flexibility for customizations without code exposed through Metadata, Salesforce delivered on gaining customer trust from small businesses through to global enterprises to quickly become the world’s #1 customer relationship management (CRM) and define the model for a successful Software-a-Service (SaaS) business.

Over the years, the platform has grown through aggressive acquisitions and tri-annual releases. Far beyond being just a CRM application, it now provides an API-enabled integration platform, plus a full suite of industry solutions, which are typically integrated at the heart of many businesses’ IT estates. In addition, Salesforce understood how to establish and enable a rich ecosystem of ISV and System Integrator (SI) partners to deliver a global ecosystem estimated to be worth over $123bn per annum.

As we now enter this new era of AI-driven tools, data governance compliance rules, and increased IT security threats, it’s even more important that teams understand how their data is processed, integrated, categorized, and secured from malicious access. Incorrect data use or handling can have dire consequences, as we have seen with many news headlines over the last few years.

With that change in the scope of how the platform is used, the need to manage changes, architect solutions, track dependencies and manage user roles and communication has grown at a rapid pace. The user base has also changed from primarily internal staff to customers, partners, and even consumers through the B2C Commerce and Marketing cloud acquisitions.

To manage these ever-complex implementations, the role of a Salesforce professional has changed from an Accidental Admin (often a Sales Ops or Service individual without traditional IT training) to require experienced Salesforce architects and solution architects. Salesforce Architects now play a pivotal governance and design role in managing changes to sometimes fragile legacy implementations, tactical integrations, and duplication of data. The decisions they make affect platforms outside of the Salesforce landscape, multiple Salesforce environments and applications, ensuring their businesses can embrace the constantly changing platform to improve business operations and be custodians of their platform security while continuing to allow rapid development and innovation. This approach is critical for ensuring the long-term success of these scalable solutions.

The role of Metadata in Salesforce

Metadata is quite simply data about data. Let’s take a simple example. If you wanted to capture a Company Name field, you would typically need to define the data type (text), the maximum length (100 characters), and whether it was optional or required. These attributes are metadata about the Company Name field:

• Label: Company Name
• Type: Text
• Length: 100
• Required?: Yes
• Default Value:  <blank>
• Metadata API Name: Name
• Parent Object: Account
• Description: The company’s legal entity name is registered
• Help text: Enter the company’s legal entity name, and check for duplicates.

Note that the field has both a Label and a Metadata API Name. This ensures we can have regional variations of the field label that each user sees based on their preferred language while having a single reliable, ideally immutable name of the field for reference elsewhere, such as in a formula field, page layout, or Flow. This can also help us identify the same field across different instances of Salesforce.

Metadata does not just describe how we capture and store data; it also defines how we can interact with it. A field may have validation rules, be used in a workflow to automate processing, be referenced directly in code, or be accessed externally via automatically created APIs for integration with other systems. A metadata API defines the set of available attributes for each type of metadata.

Unlike a label, metadata is always uniquely named – within a specific Salesforce instance (defined as an Org).

By using metadata and prebuilt object definitions for standard entities like Contact, Account, Case, Opportunity, Lead, Asset, etc., Salesforce also enables ISV partners, consultants, and developers to have a common understanding of the data structures and unique customer configuration. This uniformity is crucial for solution architecture to ensure consistent and scalable business applications.

Salesforce allows users with System Administration privileges to extend this model with custom objects, Custom Fields, Custom Objects, and additional metadata to describe their unique configurations. If they do not complete the descriptions and help text associated with these customizations, then the only guidance successive administrators may have is their Sherlock Holmes detective skills.

APIs and their functionality

Application Programming Interfaces (APIs) are a mechanism by which data can be exchanged across technology applications on disparate platforms. Salesforce automatically creates REST and SOAP interfaces for every new custom field or object. The access to these APIs is controlled using an advanced permission function, which can be problematic to manage and verify if poorly implemented but allows fine control of both function, object, field, and record access. 

Architects, Developers and advanced Admins (ala Adminelopers) can also create custom APIs to provide specific services using the Salesforce platform, both directly in Salesforce using the Apex development language and via Salesforce extension products such as Mulesoft.

Salesforce also provides several Metadata APIs to help ISVs and consultants backup, manage, package, and deploy changes across Salesforce instances. Rather than accessing business data, these Metadata APIs only handle the read and write of the metadata itself, not the data records within an Org. In the new AI era, we’re seeing applications that can use metadata to make recommendations on how to implement changes or automate business processes from a user-based query or prompt.

Security and trust in the cloud

Trust is Salesforce’s #1 value. For obvious reasons in terms of custodians of their client’s data security, but also in adopting ethical practices, customer success, and investing in constant innovation. While always established with a strong security model, as we moved from pre-COVID, perimeter-based security to a hybrid working environment, both Salesforce and other vendors have adopted a zero-trust policy. This has led to rapid changes in the platform, rapid roll-out of Multi-Factor Authentication (MFA), and a shift from User Profile-based permissions to a more granular and easier-to-audit permission set model.

While Salesforce provides the capability to implement Zero Trust compliance, it’s the Admin and consultant’s responsibility to implement, adopt, and maintain that compliance. It’s the Architect’s role to govern and identify changes that put that compliance at risk as early as possible, using architectural thinking to foresee potential security issues.

This includes both configuration of field and record access, plus analysis of customizations that have the potential to run in “system mode” and bypass the default security model. Salesforce released free Platform Integration user licenses to help teams of all sizes ensure they did not reuse user credentials for system integration. Following a zero-trust policy for integration ensures that access to every application, both on and off the platform, can be controlled by the Org’s system administrators.

Integration with other applications

As we mentioned earlier, Salesforce is often highly integrated with other external systems. Being able to visually document these integrations and map dependencies at the data and functional level allows Salesforce architects to document and manage their entire platform landscape. The impact of changing, decommissioning, or replacing any of these systems can be quickly traced in terms of the changes required, plus any technical debt created as a result is identified soon and planned for remediation.

Capturing the types of data, frequency, and detail of integration allows architects to avoid unnecessary data duplication, reuse technology capabilities, and view the impact of changes to business processes. 

While Salesforce supports direct, seamless integration, the best practice is to use tools like Mulesoft to implement a reusable integration platform that allows central management and monitoring of integrations. This allows IT owners greater visibility of the transaction volumes and changes over time, plus the ability to handle exception scenarios and implement recovery plans after platform outages.

This can also support the rationalization of IT systems to reduce overall expenditure and ensure future growth. 

Salesforce Well-Architected standards

Well-Architected is a cross-industry framework for standardizing best practices in solution design and delivery. Salesforce Well-Architected, shows you what health looks like and where to spend your time road mapping and designing solutions with the Salesforce Platform. It shares prescriptive guidance and examples of integration patterns and anti-patterns to look for in your landscape based on knowledge from product teams and implementation experts throughout Salesforce and its ecosystem. Salesforce Well-Architected is organized to help you build solutions that are Trusted, Easy, and Adaptable. 

Salesforce well-architected includes diagram standards to ensure that visual communication is repeatable and easily understood by Salesforce professionals using a common UI template. A library of pre-existing content for Salesforce out-of-the-box solutions is also available. Generally, documents should use a hierarchical structure to communicate up to 4 levels of detail where needed.

Key Points to consider when implementing Salesforce

Due to the highly customizable nature of Salesforce, plus the marketing of the power of the platform, platform owners often have high expectations of what can be achieved. Whilst Salesforce implementations are accelerated when compared to traditional technology development, some fundamental principles are still worth following to avoid the creation of a messy, poorly implemented, and potentially insecure implementation.

Setting clear objectives and goals for Salesforce implementation

Before undertaking a new Salesforce implementation or major enhancement, it’s vital that the key stakeholders are identified, committed to the project, and clear on its scope. To manage expectations, a steering committee or Center of Excellence (CoE) is an excellent way to ensure decisions are made quickly and with full transparency.

An implementation plan should include not only the resources and timeline to configure or develop solutions but also effective engagement with stakeholders on the business processes to be automated, the benefits any automation will bring, and current pain points that need to be addressed. Having clear objectives and goals will allow the CoE to effectively assess and govern changes to avoid focusing time on distractions.

In addition to having clarity about what needs to be implemented, including documentation about how the solution will meet those business requirements and deliver the required outcomes ensures that this information is not lost after the initial development. This information then influences subsequent decisions on security, integration, and analytics and forms the basis for user adoption and user acceptance testing.

After implementing your project, you also customizations to put in place an effective monitoring programme. This can be as simple as running regular adoption dashboards and data quality reports and engaging stakeholders to support and act on deviations from the agreed goals. Minor changes can be quickly made to get the project back on track, updating any documentation as part of the process.

Collaborating with development teams in Salesforce architecture

Companies may choose to implement Salesforce themselves, hire individual consultants, engage a Salesforce SI partner, or use a hybrid combination of these resources to undertake their project delivery. Regardless of how you create your team, you need experienced consultants who carry responsibility for knowledge transfer at the end of the project delivery, plus trained resources to manage the platform on an ongoing basis.

The majority of Salesforce implementations follow Agile methodologies such as Scrum. Work is defined in User Stories written in the perspective of the end user, and articulating the value it will bring. Stories are collected together into time-boxed Sprints to enable a continuous delivery mechanism.

To succeed with this approach, it’s also necessary to elaborate the user story with additional information, such as the acceptance criteria and a design of how the solution will be delivered. INVEST is also a popular checklist for evaluating the quality of a user story:

• Independent (on all others)
• Negotiable (not a specific contract for features)
• Valuable (provide business value or to the end user)
• Estimable (to a good approximation)
• Small (so as to fit within an iteration/sprint
• Testable (in principle, even if we don’t have a test for it yet)

By defining high-quality user stories, there is less need for an Architect or Business Analyst to explain changes to a developer (or Salesforce Admin), or for the developer responsible for implementing the change to need to speculate or have a different interpretation of what is required.

Where developers need clarification, they can communicate through the user story with the affected stakeholders, architects, and analysts to document any decisions or clarify requirements. At the end of development, the developer will normally use both static analysis tools to verify the quality of their work and/or a collaborative peer review process. Having good documentation minimizes both the time to carry out reviews plus sets clear guidelines around the scope and impact of the change for everyone.

After completing a story, a developer moves on to the next work item, normally leaving other team members to deploy, test, and educate users. 

Summary

Mastering Salesforce architecture is essential for aligning your business strategy with the capabilities of this powerful platform. By understanding its wide range of features, from metadata management to robust security protocols, businesses can effectively integrate and optimize their business applications. This ensures not only a seamless operation today but also positions the organization for future growth and success in an ever-evolving digital landscape.

FAQs

How do you master Org dependencies in Salesforce?

Mastering Org dependencies in Salesforce starts with documenting integrations, data flows, and customizations. Use architectural thinking to map dependencies and assess the impact of changes. Evolve and mature your content to increase the maturity of the documentation you hold over time.

We’ve outlined how you can leverage the Elements.cloud Change Intelligence Platform, to capture, identify, and explore dependencies, in a recent blog post. Learn how to master Org dependencies today, by reading the full article.

What skills are required to be a successful Salesforce Architect?

A successful Salesforce Architect needs deep knowledge of Salesforce platforms, strong problem-solving skills, and experience in solution design and system architecture. Effective communication and leadership are also key for managing teams and projects.

What is Salesforce implementation?

Salesforce Implementation refers to the process of setting up and configuring Salesforce applications to meet a business’s specific needs. This includes customizing the platform, integrating it with other systems, migrating data, and training users. The goal is to tailor Salesforce to support the organization’s processes, improve efficiency, and achieve business objectives.

Is it the right time to implement Salesforce CRM? 

It’s the right time to implement Salesforce CRM if your business is growing rapidly, struggling with disorganized customer data, or facing challenges in managing sales and customer relationships. If your current systems are outdated or can’t scale with your business, Salesforce can help streamline operations and improve customer engagement. Assess your business needs and readiness to decide.