This site is in beta. We welcome your feedback
Diagrams are a key part of architectural work. Diagrams communicate ideas to many different kinds of stakeholders, with many different needs. Diagrams help delivery teams stay aligned, by serving as a single source of truth about the realities of implementations and products. Diagrams are also critical to empowering business stakeholders to make the right purchasing and technology choices. Unfortunately, a single diagram typically cannot convey meaning to every possible stakeholder. Most diagrams only convey meaning to a specific set of stakeholders, for a specific purpose.
It can be difficult to know what type of diagram best supports a given scenario, what kinds of data can and can't be shown in various diagrams, or what kinds of diagrams best communicate with different stakeholders.
We developed this guidance to empower everyone to build accurate and understandable Salesforce diagrams. The resources provided here and in the links below will help you get started building your own diagrams with a predictable, standardized look and feel.
We categorize diagrams into two general styles, based on purpose and intended audience. Clarifying the intent of the diagram you're trying to create is a critical first step in creating something that will resonate with your intended audience. Below, you'll see an overview of the two styles for Salesforce diagrams: Documentation & Implementation, and Marketing, Strategy & Sales.
Purpose: Help viewers understand an implementation or product-related technical detail.
Audience: Delivery Teams, Technical Stakeholders
Purpose: Help viewers understand concepts or a vision for a solution.
Audience: Business & Executive Stakeholders, Technical Influencers
Being clear about the intentions and audience for your diagram is an important first step. After that, you have to decide what kinds of details best support your purpose. This is where diagram levels come into play. We use a concept of 'levels' to help separate different kinds of details into easy to choose categories.
Selecting the right level for your diagram helps you communicate with the right amount of detail, which means even highly complex diagrams can still be easy for a viewer to understand.
As you move from Level 1 → Level 4 you zoom into greater levels of detail, finer granularity, and reduced surface area or scope. Below, we look at what these levels mean for each diagram style.
The concept of using levels to convey different kinds of detail is common to many frameworks, including the C4 model
For example templates, see Documentation and Implementation Diagram Templates
| Key Characteristics | Documentaion & Implementation Diagram Levels | |||
|---|---|---|---|---|
| Level 1: The Big Picture | Level 2: Piece of the Whole | Level 3: Process or Interaction View | Level 4: The Double Click | |
| Scope | System landscape or solution overview | A subset of a system landscape or solution | Limited view of products or technologies in a solution, focused on showing more complex detail | Most narrow view, focused on showing fine-grained details |
| Audience | Business and executive stakeholders, technical stakeholders, delivery teams | Some business and executive stakeholders (example: a product owner), technical stakeholders, delivery teams | Technical stakeholders, delivery teams | Technical stakeholders, delivery teams |
| Elements | Actual products or technologies in a specific implementation | Actual products or technologies involved in specific pieces of functionality, services, interfaces | Time-based interactions or data flows, or system interactions required to support a process | Fine-grained technical specifications or requirements |
| Example Diagram Use Cases | System Landscape | Integration Layer | Authentication Flow | Data Model (ERD/UML) |
| Key Characteristics | Marketing, Strategy & Sales Diagram Levels | |||
|---|---|---|---|---|
| Level 1: The Big Picture | Level 2: Piece of the Whole | Level 3: Process or Interaction View | Level 4: The Double Click | |
| Scope | “Art of the possible," digital transformation scenarios | Business capability or solution overview | Business process or user journey | Fine-grained detail about a capability |
| Audience | Business and executive stakeholders, technical stakeholders, delivery teams | Business and executive stakeholders, some technical stakeholders (example: architects), some delivery team members (examples: delivery lead, admins) | Some business stakeholders (exampe: product owners), some technical stakeholders (example: architects), delivery team members (examples: delivery lead, admins, devs) | Some business stakeholders (exampe: product owners), technical stakeholders, delivery team members (examples: delivery lead, admins, devs) |
| Elements | Business capability or solution overviews | Specific technology or product subsets, showing a specific business capability or solution | Components with personas, relationships, timing and some finer detail | Components with personas, relationships, timing and finest-grain details |
| Example Diagram Use Cases | Reference architecture, blueprint, value map, capability map, etc. | Solution architecture | Journey map, business process | A step or portion of a business process |