One of the reasons you build this type of diagram is to set up the authorization rules and to illustrate what types of features certain individuals or an API client is going to have access to.

The four main elements that are
- Use Cases
- Actors
- Subsystems
- Relationships.

Use Cases are represented by a circle and typically have some type of action. This is something that is very important when it comes to building these types of diagrams, we're trying to illustrate what types of actions and functionalities that an actor has access to. Right here we have a couple of examples, one is "get reports" the other is "get messages." We like to have very action-oriented types of elements because it makes it much easier to see the types of features that a user has access to.

Notice we don't care about things like the data attributes or direct methods, the goal is to give these to developers and have them know how to build an entire authorization engine. They can see what types of features one type of user has access to versus another type of user.

The next element is the actor. One thing I want to point out, an actor can be a human (Admin or Customer) but it can also be a non-human like an API Client.

Imagine a scenario where you're building an API. That API is not going to have any kind of users accessing it, you may have a mobile application like an iOS app or a front end app that accesses it but you're never technically going to have a user. With that in mind, it's important to think of actors as also being different types of software clients.

An example of that would be if you're building an API and you give the ability for other API/websites/mobile apps to query your API and pull in a list of blog posts or users. You'd build a use case diagram and say that this API client has access to be able to perform the following tasks. I wanted to make that clear, I have taught UML through the years and I typically see actors always being listed as humans, however, they're any types of actors that have access into the system.

The next element is the subsystem. Focus on the large rectangular box that says "web dashboard," this is a subsystem. Subsystems in a use case diagram are represented by large rectangular boxes that have use cases and different elements inside of them. You may notice that we have items such as:

• get reports
• get message
• manage contacts
• visit resources
• forms

all inside of this web dashboard element.

The items that are outside are::

• managed journeys and shapes
• trigger journey's events
• get notifications regarding journeys

Those items are all outside of the web dashboard/subsystem. Subsystems (also called system boundaries) are different elements that you can place inside of a use case diagram to help you organize and see where these types of use cases are actually going to occur.

Lastly, use case diagram relationships. Relationships are represented by dotted lines with open arrows. This shows how you can go from one use case to another use case. This gives you the ability to connect your actors directly to the use cases and to the elements and actions that they have access to in the system.