We have a use case diagram for a marketing automation system, this has all the elements that we've walked through with using Use Case diagrams.

Looking at the marketing specialist, you can think about them being an admin user for the system. If you follow along to see each one of the different use cases they have access to. You can see at the very top they have the ability to:

• manage journeys and shapes
• get notifications regarding journeys (you can think of a journey as a marketing lingo where it gives you the ability to track users from lead to sale)
• get a notification on that side

Next to notification you see that we have a relationship that says "notify." That gives us some guidance on the processes that will happen. If we go from "trigger journey events", that has to connect to the marketing specialist getting notifications, so they're going to be notified.

Moving down, we have our subsystem of the web dashboard. This is where each one of these five elements is going to be included.

• get reports
• manage contacts
• generate forms

they can do all of this from within the web dashboard.

The customer (you could also call them a lead) has access to a number of things. For example, it can trigger a journey event by signing up with a company's website sign-up form. They would then get a message and they can visit resources and fill out forms. This gives a nice level of visualization when it comes to seeing what types of functionalities and features every user in the system has access to.

If an engineer handed me this type of diagram I would be able to see that we have a web dashboard that's going to:

• have a reporting interface
• it's going to have messages
• it's going to have resources
• a spot to manage contacts
• spot to manage forms

Then by looking at the actors, I can see what each one of them has access to and which one of them should be able to do things like getting notifications. When I see notifications at the top and I see it's not inside the web dashboard, that tells me that I'm going to build an email system to notify the marketing specialists each time a change happens from that lead.

When I go into the web dashboard and I see where it says "generate forms" that tells me that I'm going to have a number of components to build. On the form side of things, I need the ability to create dynamic forms that the specialists can build, then the customer needs access to see them and fill them out. That's going to feed into reports. This diagram may not be that big, however, with these eight different use cases I see a lot of functionality. This goes back to one of the entire purposes behind UML, this small diagram would take pages of written content if somebody told me this by hand.

By building a diagram like this I can see

• what users should be authorized to do
• I can see different components that are going to be available on the pages
• I can see features such as notifications, journeys, and rules

This is part of the reason why UML has been around for decades and hasn't changed a lot, you can utilize a lot of power by using these simple tools. Notice how we are only using four elements inside of this use case diagram and we've modeled an entire system.