In the previous article, “Synchronizing Customer Data, Part 1: Discovery” we gathered basic requirements of customer data usage across the enterprise. We identified systems and stakeholders in several groups and how they interact with this information.
Now we will turn our attention to the design of our solution. The first step is to lay out all the data structure from our various systems and start to understand how they are related to each other. We label this defining the Information Architecture.
Information Architecture
There are several ways to document the lists and fields associated to each system and how they relate. Visio’s “Crow’s Foot” database notation template is a good place to start but notepad or excel would work just fine. In the diagram below we have illustrated the data schema in each system as well as their primary keys, foreign keys, and relationships to each other.
This diagram will be helpful during implementation to ensure we’re getting and setting the right field values across our various systems.
With an understanding of the data structure involved we can now start to lay out how the workflow will keep this information synchronized across these systems.
Workflow Diagram
Workflow can sometimes be the hardest part to get right during the design phase. Regardless how much time is spent documenting the process, more than often it ends up being an iterative process.
We start by understanding what will trigger our workflow. Sometimes workflows need to be run on a timer so that the actions are executed hourly, daily, etc. In our case, we know where the Customer data will be first entered into the system (by the Sales team in the SharePoint CRM) and therefore, we can trigger the data sync process off of that origin point.
The following workflow diagram defines the trigger, then shows step by step each action the workflow must take to ensure the Customer data is sync’d across our various systems.
You’ll notice in the first step we are creating a “term” in SharePoint, also known as metadata or tag. Creating this item will allow us to greatly increase the findability of other Customer related content across SharePoint as the Term Store is globally accessible and a metadata “Customer” column can be added to any data list or document library. This proves very useful when surfacing data to our users as we can pull back any content tagged with a specific customer into search results or dashboards.
To wrap up the design phase we will next lay out the steps involved to build the workflow.
Implementation Strategy
Before starting implementation, we will need to know what tools we will be using to build the workflow and in what sequence do we need to establish in order to build out the solution.
Workflow Tools in m365/Azure: Logic Apps vs Power Automate
Microsoft has created two great tools in order to implement workflow. Azure Logic Apps and Power Automate. The differences between to two are minimal when it comes to the user interface and available workflow actions. However, the pricing models of each do vary and the easiest way to sum it up is that Logic Apps are billed by consumption, authors do not need a license to build them. Premium actions are also available to Logic Apps. With Power Automate the cost is baked into the license which is tied to the user’s m365 license. Premium actions in Power Automate also require the premium Power Platform license in order to use them in your workflow.
There are some other advantages to using one or other and depending on who is creating the workflow, what features they need and how the workflow will execute all can help determine what tool to use.
We will be using Logic Apps in this article to implement our workflow.
Wrapping Up Design
Armed with our design documents and strategy we are ready to break ground on the build out. In the next article: “Synchronizing Customer Data, Part 3: Implementation” (coming soon) we will implement our design and run some tests.