Dynamics 365 Architecture: Event Driven Architecture for Business Automation and Integrations

Signals or what is more commonly known in developer lingo as events are notifications that indicate the fact that something of significance has happened. Events are meaningful and relevant in the business system context and are very helpful in creating loosely coupled business automation that does not create fragile dependencies. They act as hooks separating the source event from the actions taken that makes a system design more robust. In the context of Dynamics 365 systems, we can use this domain event pattern to design for greater extensibility, maintainability, and scalability.

Business Automation Challenges

If you've looked at any sizable Dynamics system one thing that can become daunting is the number of business automations to manage. There aren't many things more daunting as needing to create new business requirements across hundreds of workflows, flows, plugins, business rules, and JavaScript libraries. If you include consideration of external integrations and third-party solutions inside your application, you can have an interesting task on your hands.

The most common configuration I see on most projects is that each business automation triggers on its own defined event.?The usual reason for this is that different customizers have created business automation for their task item in isolation of other requirements. What you’ll often find is there are other business automations that trigger off the same criteria. The problem is if the logic changes for one workflow it may need to be changed for many others as well. It's at this point you may have to go hunting for other workflows and plugins that execute on the same trigger criteria because it changed. This usually leads to some things being missed because nothing is connected to a common event model.

A way of looking at the trigger logic of your business automation is they suggest a relevant business event has occurred. When the criteria are left in each individual business automation it means the actual business event has not been defined explicitly. When you get a requirement that says when customer type field changes to another value this other thing happens there is an implicit event we should flush out. Ask yourself the question, if we were going to call this event something what would we name it? Then you can ask what else should happen when this event occurs? How can we explicitly define this event and then use it to trigger any other required automation? By undertaking this process throughout your business logic you're defining the domain events that are relevant to your system. These domain events can be exposed externally such that other systems can then subscribe and perform their own actions based on them.?For example, by utilizing an Azure Service Bus topic you can extend your business logic out to one or more subscribers that can operate on their own or even orchestrated with something like an Azure Durable Function.

Migrating to an Eventing Model Mindset

Imagine you have 5 workflows that execute based on the same trigger criteria for a lead. The way to look at this is when the trigger logic must change you now have to change the trigger criteria of 5 different workflows. I’ve had to do this when the system had dozens. So, imagine what happens if we separate the trigger logic from the work being performed.

Figure 1: Multiple Process Triggers

By formally defining the business event we could use it as a hook to hang business automation on. This would mean if the trigger criteria changed we would only have to update a single component as opposed to every individual workflow.

Composing Business Events

When Actions were introduced to the Dynamics platform I considered the scenarios where they strategically made sense. The interesting thing about Actions is when they are raised the platform sends out an associated custom message which means they are observable by both workflows and plugins.

Figure 2: Composed Business Events

Other integrations can then be added or removed without any necessity of changing the eventing system. The fact that this operation can happen asynchronously also helps with system scalability. You can obviously combine an eventing model with other design patterns to create even more elaborate integrations.

Conclusions

I can assure you that if your system is designed with an eventing model it makes updating business logic much easier when the requirements eventually change over time. Like I mentioned earlier, this is something that may happen initially as you must dig deeper into trigger patterns to see the commonality. You may stumble onto common events, but unless you actively look for opportunities to design systems with this mindset it will not happen. If you have multiple developers assigned work, they may never speak to each other about how they completed their own story, and no one is the wiser. In my opinion this is a role well suited for the solution architect or technical architect to take on as it’s more of a big picture perspective. While this article is just scratching the surface of building a domain event model it is something that you should think about and consider when designing your next implementation.

Resources

• Create Your Own Actions (Microsoft Docs)