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 circle represents the system you are modelling. Important: there is only ever one of these.
The External Entity – Rectangle
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
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.
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.
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.
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).