This is going to be the marketing automation system, this is the part that manages the CRM connection. This one is relatively straightforward, my personal preference is that I try to keep my state machine diagrams as simple as possible. When I build one of these diagrams, I attempt to take a piece of complex behavior and visualize it in a way where I can see each of the states that a user or client (or any type of component that I'm trying to track) is changed and see what could make that occur.

Starting at the top, our starting point is of a user (that user's very first state is being a visitor). First, I check to see if have they submitted the form, if they have not, their state has not changed and they're still a visitor. If they have submitted the form (for this case I made a straightforward example, we assume a form means that they have registered and they're moving forward in the process. We can have different branches, based on the decision they may not be only a visitor or converted, they may be a converted visitor and depending on their decision they may go into a Do not contact list) for the sake of the example, we're going to say we have an option where their first state is a visitor then they submit a form then their state is converted.

Now we just asked another question and we see are they qualified for the CRM conditions. If they're not they may be converted but they are not a lead. What that means is that they would stay in that converted state and we would have a way of tracking that.

Part of the reason why I like this example, it is similar to how the sequence diagram worked. Notice how this type of diagram does not specifically give instructions on how to build the system, it doesn't give instructions for what the class name should be or what programming language should be used or anything low level like that.

I like to use state machine diagrams for building a requirements list for a client or for the company that I'm working with. As you can see, this is a diagram where you do not need to be an engineer to understand how it works. I have had many times where I built a state machine diagram for a freelance client who couldn't really give a good idea of the type of project behavior that they wanted. I built this type of diagram for them and said OK I have listened to what you had to say and this is what I think you were trying to describe. These are all of the different potential states that a user could be and these are the most important questions that either we're asking them or that we're checking inside of the data for.

The first item was did they submit a form? That's something we're checking against the user's action and behavior. The next one asks if it says qualified for the CRM conditions, which is not asking the user a question, that is asking that data a question.

Say the visitor comes to the site, they fill out that form and then the next step they're converted. Then we run a check against the requirements are in the system to see if they qualified. This is where things are very different from an activity diagram, it may look similar where we have a user who's a visitor then they go to another page and fill out a form and then they perform these other actions. However, this is not the case here, In this case, we're only caring about the state of the user.

They started as a visitor then they became converted. That doesn't mean they went to a different page or anything like that, this could all happen while they're filling out the form. It may be something as straightforward as saying that they submitted the form and then during that process it checked and it may have changed their state to converted but it didn't transition them to be a lead. This is something where that qualified for the CRM conditions is probably just a database or an API query.

Moving down the line, you can see that we have a lead and we have another choice, we check to see did they qualify for a CRM opportunity condition.

We have a couple of validations, we have an initial one, then we go and we say OK we see that they fit the first set of conditions (that might be as something as straightforward as checking to see if they live in the US. When you're a U.S. based company that only does business domestically) and once it gets to this other stage we do not want to test and run a large number of queries until they've passed it.

Imagine this is for a mortgage company. If you say that you're interested in a mortgage and you fill out a form online, you are going to turn from a visitor into converted. Then you're going to be a lead, however, you still have not actually entered in any information that the mortgage company needs to know so they can get you a loan. You may have typed in your zip code or something and they know that they can potentially do business with you but they don't know if they've converted you into being somebody all the way the point where you have a credit score that matches and all of these other criteria. Your state is changed, your visitor converted and then you're a lead. All of these items are probably just one column in the database like an enum or something that has just gotten updated as it has checked for validations.

Using the same mortgage industry example, now it checks to see if you're a qualified opportunity, they may then ask the user for their social security number, address and income and those kinds of values and check to see if you are a full opportunity.

From there your state has been changed, then the system continues on all the way down to if the salesperson closed that individual or if they moved on and they decided not to go with them. This is a very standard kind of process in many types of CRM systems where you need to manage state.

Another great example of when to use a state machine diagram is building an approval engine. This is something I've had to build many times, something to check to see if an object in a database is approved or not.

I built a system for a company where they wanted to see if a certain vendor could be approved, they had hundreds of different locations and the location was in charge of submitting a vendor approval request. That was the initial form that got sent, it was in a pending status. Then it went through a series of different checks.

Some of them were automated, they would check to see if it was under a certain threshold amount. If so, it was pretty much approved automatically, if it was for a larger amount than it would go through other states.

Each time it would have to change the state, I'd have to reflect that in the database. it would do something like ask a supervisor "one" and if approved it would move on and it would be updated for approval number two those kinds of things. Each situation's going to be a little bit different but that's another example of when building a state machine diagram is a great way of visualizing data flow in the sense of how your data is going to change as different events occur.