When to Use Elements for Salesforce Architecture Diagrams?
Use Elements.cloud to define and visualize your Salesforce technical architecture when:
Designing new systems that need to grow with your business
Evaluating existing system interactions for data load and transit impact
Needing to identify system bottlenecks and suboptimal data flows
Elements supports hierarchical, multi-level architecture diagrams. This allows you to capture solution details at different levels of abstraction, geared towards different audiences.
Why Create Salesforce Architecture Diagrams?
Architecture diagrams are essential because they communicate complex technical ideas across a range of stakeholders, each with varying perspectives and needs. From developers who need to understand implementation details, to business leaders who are more concerned with high-level system interactions, a well-documented architecture ensures everyone is on the same page.
By capturing these diagrams, you ensure that:
Business stakeholders understand the broader context and can ensure that the solution aligns with business goals
Architects and technical leaders can assess the system's scalability and performance
Developers build what is required, with a full understanding of how different system components interact and the business context of a solution
Managed service contractors can understand the context and undertake impact analysis of future changes
Auditors can access necessary documentation for the purpose of regulatory compliance and security audits
Without clear, structured diagrams, teams risk misalignment, incomplete understanding, and slower execution on projects.
Watch the video below (we recommend you set it to 1.2x speed! ) to understand how Elements supports architecture diagramming.
Prerequisites
Architecture Diagrams license (part of Professional and Enterprise license package)
Edit rights on the space
Design your System Architecture
Step 1: Create a new map and draw a System Landscape Diagram
First, create a new map. Give it a title, like '[Company name] system landscape'.
Decision: what should be the scope of the system landscape?
Decision: what should be the scope of the system landscape?
You can either capture the 'full' system landscape, or 'use-case' specific landscape.
The full system landscape includes ALL systems used by the organization and relationships between them. However, in large organizations that utilize many applications, this could be too overwhelming.
The 'use-case' specific landscape only focuses on systems that come together to support a specific use-case, or work around specific system. For instance, you could create a system landscape that only includes systems connected to Salesforce. Or all systems that play a part in order management.
Start by capturing blocks for each major system and mapping relationships between them. On the flowlines, add text indicating what sort of data is flowing between the systems.
The system landscape diagram is good for providing 'high-level' overview of the systems being used by the organization. However, it should not be too detailed.
Avoid the following:
Low-level details or internal configurations: Avoid adding internal system configurations, database schemas, or overly technical details that are better suited for system or data flow diagrams.
Individual user workflows or tasks: The diagram should capture systems and their interactions, not user-specific actions or steps within applications. These details are better suited for business process diagrams.
Data fields or individual transactions: Keep the focus on the systems and relationships; granular data or individual transaction flows should be reserved for system interaction or data flow diagrams.
A system landscape diagram is a good resource to use with business stakeholders to validate desired outcomes, as well as with developers and architects to set the context for the project.
Step 2: Drill Down to capture System Interactions
System Interaction diagram is a more detailed picture of when and how different applications interact with each other in a sequential flow. A System Interaction diagram is also focused around a specific use-case.
System Interaction diagram should include:
Data Format and Flow: Clearly depict what data moves and how between systems, using arrows and labels to specify the type of data or actions being exchanged.
Integration Mechanisms: Specify how systems interact, whether through APIs, webhooks, or middleware platforms, to explain how communication is facilitated.
Triggers or Events: Indicate what initiates the interaction between systems, whether it’s user actions, scheduled syncs, or automated system events.
Data Volumes and Frequency: Represent the data volumes and frequency of operations between systems, highlighting the scale of data being exchanged and potential performance impacts.
Type of data being moved: Document what sort of data will be moved between systems. If any customer information, like email, account information, name etc. is to be moved, document that as this needs to be discussed and cleared with relevant stakeholders.
A System Interaction diagram can be captured as a stand-alone diagram. However, we recommend that you pick a system that is central to a given use-case and instead create a child diagram to embed the Systems Interaction within the overall landscape.
Click on a card representing a system in the landscape diagram.
Create a child diagram using the context menu option.
Capture detailed interaction, including order, data volumes, events and triggers, and other detailed information.
While System Interaction diagrams are fundamentally a design tool for architects, they are also useful for engaging business stakeholders, as they provide detailed insight about the scenarios but without overwhelming technical detail.
Step 3: Capture data flow / transaction logic diagram
A data flow / transaction logic diagram is visual representation that illustrates how systems, components, or entities communicate and interact with each other to execute specific processes or logic. It shows the flow of data, control signals, or messages, as well as the conditions or triggers that dictate system behaviour.
A data flow / transaction logic diagram is the foundation for building integrations and automations, and lays the blueprint for how it should work.
Data flow / transaction logic diagram should be an asset used to collaborate, discuss, and brainstorm most optimal solutions. Using sticky notes, you can document decisions and comments on why something was built in a certain way.
Click on a card representing a system in the interaction diagram.
Create a child diagram using the context menu option.
IF there are multiple different scenarios being executed by the same system, you can capture separate box for each one and then create another child diagram to capture the detailed flow.
Capture detailed logical steps, including object types, fields, decision points, volumes, triggers, and operations in a sequential order in which they are done.
Tip Data flow / transaction diagram is a blueprint for your solution. It is a good layer to capture specific metadata components from your Org against diagram steps.
Step 4: Model data relationships
A data model is a structured representation that defines how data is organized, stored, and related within a system. It outlines the entities, attributes, and relationships between different data elements, providing a blueprint for how data is managed and used in databases or applications.
Whilst you can create data models / entity relationship diagrams as stand-alone diagrams, we recommend that you capture them within your architecture hierarchy.
Tip Consider attaching metadata representing specific Objects in your Org to entities in your data model. That way you are always one step away from exploring usage, configuration, and automation dependencies for a given Object.
Using hierarchical approach to solution design
Watch the video below, demonstrating how to use the outlined hierarchical approach to solution design in practice: