How to draw a system context diagram for your Salesforce project

Hello and welcome to the first post in a series of lessons on how to create excellent technical drawings for your Salesforce project.

The first one is the System Context diagram, and I was inspired to start this while making toast for my children this morning. This is a handy diagram and is used for describing the system you are building, and the systems and personas that interact with it, at a very high level. They are straightforward diagrams to draw, and I think that with a few pointers, anyone should be able to pick this up.

I will start by explaining what the required shapes are and what they mean, and then work through a couple of simple examples.


A system context is a very simple diagram and there are only 3 shapes to learn.

The Process – Circle

The Process

The process circle represents the system you are modelling. Important: there is only ever one of these.

The External Entity – Rectangle

The External Entity

The external entity is something that interacts with the system. There can be many of these. They can be humans or other systems.

The Flow Line – Arrow

The Flow Line

This is a data flow line that describes the data being transferred and the direction of travel for that data

Simple example by analogy – Toaster

So as I said above I was inspired while making breakfast this morning and I thought the experience of making toast would be something very simple to model as a system context diagram.

Very Simple Example – Toaster System Context

So let’s work through this:

  • The Toaster is the system we are modelling. We only care about what it does and who interacts with it within the scope of this diagram. We don’t care about how the Toaster actually works internally at this stage in our design work.
  • I, as the Breakfast Maker, am the external entity to the toaster system. I want to interact with the Toaster system in some way.
  • I put bread into the toaster, and I get toast out of the toaster (represented by the flow lines).

Simple example – Google

This is another good simple example that only has one process and one external entity.

Google System Context Diagram

I like this example as it illustrates how much complexity is hidden by this type of diagram. Google is clearly an incredible piece of software and has an untold mountain of processes internally to be able to serve up useful search results. In this diagram however we just hide all that. From a System Context perspective it is no more complex than a toaster. The search user provides it a search term, google returns some search results. A lower level diagram that looks a bit like a system context diagram, called a data flow diagram, can drill down further to give more insight into what is happening in the system process. I will cover this in a later blog post.

Salesforce example

Salesforce Example

Here is a simple Salesforce example, where I have scaled the diagram out a bit to include an additional human external entity and a non human system external entity.

The Sales User submits opportunities, some of which will get to closed won. When this happens Salesforce will do a bunch of stuff, and show the sales user some nice confetti. They are also notified when their commission is approved.

The Sales Manager receives notifications of any closed won opportunities. They have another interaction modelled here where they approve the commission.

Finally I have added an invoice system just to demonstrate that a non human actor is modelled in exactly the same way.

Note despite my explaining this in a sequence, the sequence of events is not modelled here at all in this diagram. Sequencing would be a much lower level diagram called a system sequence diagram which I will cover in a later blog post.

If you have any questions please leave a comment or reach out on one of the social platforms (buttons in the header).

Subscribe to the blog

2 thoughts on “How to draw a system context diagram for your Salesforce project

    1. Hi Sam, thanks for the question, a System Context is used to show your whole solution from a very very high level, whereas a flow chart is used to describe a specific end to end process. A System Context diagram is great for quickly organising your architectural and design workload on a project and setting the scope of what you intend to do. I would usually start a project by drawing one of these, then for each thing I note on the diagram I would then go away and decide what the correct architectural diagram/s are to describe that in adequate detail. So for example, where I have just written “Opportunity Details” on the line between the Sales User & Salesforce, that would drill down into a bunch of other much more detailed content, such as flow charts, ERD, maybe some UI design work, etc. They are also what I use when I start to tell my story from when playing back the architecture to the business. Does that answer your question?

      Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s