Salesforce to Microsoft Dynamics 365 Migration - Challenges, Strategy, Process

Salesforce to Microsoft Dynamics 365 migration involves more than moving customer data. It includes migrating or rebuilding the automations, security model, and integrations that have been built around Salesforce over the years.

Both platforms are opinionated, which means each one has its own way of running automation, security, and integration, and whatever was purpose-built for Salesforce has to be re-engineered to behave correctly inside the model-driven approach and the Power Automate framework of Dynamics 365. Companies usually make the move because they already run on Microsoft 365, want to extend the CRM on the Power Platform, or expect a lower total cost of ownership from it. It applies to any organisation that has run Salesforce for several years and now has to carry the business logic across, not just the data. For example, teams such as the revenue operations groups of insurers, brokerages, and distributors that run Sales Cloud and Service Cloud across more than one region.

Let us discuss Salesforce to Microsoft Dynamics 365 Migration in detail. We will first understand what the migration covers and why it is different from a plain data migration. Then, discuss how each Salesforce process is re-engineered in Dynamics 365, the four-phase strategy that keeps the business running during the move, the benefits, a worked example with its before-and-after numbers, and the best practices that make such a program work. Our goal is to help you decide whether your Salesforce org is ready for this migration or not.

A Typical CRM Migration is More than Simple Data or Record Transfer

Most people picture a CRM migration as an export from the old system and an import into the new one. In reality, the records are the easiest part of the move. A Salesforce org that has run for a few years carries an automation layer, a security model, and an integration layer that were purpose-built for the architecture of Salesforce, and none of them can be copied into Dynamics 365 as they are. Each of them has to be re-engineered so that it behaves correctly inside the model-driven approach of Dynamics 365 and its Power Automate framework.

Salesforce and Dynamics 365 handle the accounts, the contacts, the leads, the opportunities, and the cases in similar ways. However, the way each platform automates a process is very different.

In Salesforce, the automation mainly runs through:

• Flows
• Process Builder
• Apex triggers
• Assignment and escalation rules

All four are built into Salesforce as first-class CRM objects.¹

In Dynamics 365, the same work runs through:

• Power Automate cloud flows
• Classic workflows
• Business rules
• Plugins that run on the Dataverse event pipeline

One can say that the two platforms agree on the records and disagree on everything that acts on them.² That's why the move is not about copying the data or the rules across. It is closer to rebuilding the automation structure in the shape that Dynamics 365 expects. As such, a good migration treats the project as a re-engineering task and not as a translation exercise.

How a Small Mistake During Salesforce to Dynamics 365 Migration Leads to Serious Complications

The work is demanding because several layers move together, and each of them has been shaped by many hands over the years. Below are the layers that must be controlled during the migration:

• The data model (objects, record types, and fields)
• The automation layer (flows, triggers, rules, and approval processes)
• The security model (sharing rules and roles, which become business units and security roles in Dataverse)
• The integration layer (every system that reads from or writes to the CRM)
• The cutover window (the days when both systems are live)

Any layer left uncontrolled follows the data into Dynamics 365, and the new system starts with the same tangle it was meant to leave behind, or, in the worst case, with two systems that disagree on the same customer.

Migrations of this kind are usually proposed by the partner that also sells the Dynamics 365 licenses. That is where the plan starts leaning toward buying first and mapping later. CRM-only consultancies like Vegacompass hold the Microsoft Solutions Partner, Business Applications status, advise on five CRM platforms without reselling any of them, and the 20+ Dynamics 365 projects we have delivered include a few Salesforce migrations. For example, the published case study for FIMC (partnered with Imagene) describes an insurer's move of its account, contact, and case management from Salesforce to Dynamics 365, and it reports a 98% reduction in duplicate entries.

Why Migrate from Salesforce to Microsoft Dynamics 365?

Every company that moves off Salesforce has its own trigger, whether it is a renewal quote that grew or a Microsoft-first IT strategy. In most cases, the decision itself is driven by three things:

• The native fit with Microsoft 365
• The room to extend the CRM on the Power Platform
• A lower total cost of ownership over the next few years

You may be wondering: the migration means a rebuild of every automation, a parallel run, and months of a team's attention. So, a fair question arises: what does the company get in return?

The answer, for a company that already runs on Microsoft 365, is a CRM that sits inside the tools its people open every morning, and a smaller automation estate to maintain. Below are the main benefits of moving from Salesforce to Dynamics 365:

• Native fit with the productivity stack: Outlook, Teams, and SharePoint connect to Dynamics 365 natively, so a sales rep or a service agent works on the record without switching between apps.³ As such, adoption depends less on training and more on the habits the team already has.
• Lower long-term automation cost: Power Automate flows and Dataverse plugins do the work that many Salesforce orgs pay for through automation add-ons, and that capacity may already sit inside the Microsoft 365 and Dynamics 365 licenses the company holds. Please note that the vendor's licensing guide is the only current source for what a plan includes.
• Governance of the automation layer: Consolidating the scattered Salesforce Flows into one configuration-driven framework cuts the number of automation artifacts a team must maintain. That's why the migration is the right moment to retire the overlapping Flows rather than carry them across.
• Transactional consistency: Plugins execute synchronously within the Dataverse transaction, which closes the timing gaps that exist between asynchronous Salesforce Flows and Apex triggers. Simply put, the rule runs inside the same save, not a few seconds after it.
• SLA visibility on the case form: Native Dynamics 365 SLA timers surface the breach risk directly on the case form, instead of relying on time-based workflow rules that fire in the background.⁴ The agent sees the clock, and the manager sees the misses before the month-end report.
• Extensibility through the Power Platform: Power Apps, Power BI, and Copilot extend the CRM on the same Dataverse platform, so a new app or a report is built where the data already lives, and Copilot reads the same records. The equivalent Salesforce capabilities are usually priced on top of the seats, and here again, the vendor's edition table decides what your plan includes.

One thing to note is that the licenses alone deliver none of the above. The benefits arrive when the automation is rebuilt in the shape Dynamics 365 expects, which is the work the next three sections describe. On the other hand, a company that does not run on Microsoft 365, and whose Salesforce org is clean and well-owned, rarely gains enough from the move to justify a program of several months. In such cases, the smarter long-term decision is to fix the org and stay.

What Can Be Migrated from Salesforce to Dynamics 365?

Everything in a Salesforce org can be moved. But the important thing is to note that none move the same way. The records move first: the accounts, the contacts, the leads, the opportunities, the cases, and the activities and attachments that hang off them. Along with them, the Salesforce objects, record types, and sharing rules map to Dataverse tables, business units, and security roles. That part is mapping work. The processes below are where the re-engineering sits, and each of them maps to a distinct Dynamics 365 construct. Please note that the mapping decision for each one materially affects the performance, the maintainability, and the licensing cost of the new system.

Below, we have discussed the eleven commercial processes that come up in almost every Salesforce org of this kind. We have arranged them in nine entries, because two pairs travel together.

1. Sales Process

In Salesforce, the sales process lives in the Opportunity stages, the validation rules on each stage, and the forecast categories tied to them. Every rep moves a deal through the same gates, and the forecast reads the stage.

In Dynamics 365, the same gates become a Business Process Flow (BPF) with stage-gating business rules, so a deal cannot advance until the required fields are filled.⁵ The forecast categories and the stage-completion criteria are carried across as they are. That's why the sales team sees the same pipeline on a new screen, and the forecast keeps its meaning through the move.

2. Web-to-Lead and Web-to-Case

Salesforce ships Web-to-Lead and Web-to-Case as native forms. A generated HTML snippet on the company website creates a lead or a case straight in the org, and a marketer sets it up without a developer.⁶

Dynamics 365 Sales and Customer Service do not ship a web-to-object form generator of their own, so the forms are rebuilt in one of three ways, depending on who owns the website and what the form creates:

• Customer Insights – Journeys forms: A no-code form designer for leads and contacts, with embed code for an external page and form capture for the forms the website already has.⁷
• Power Pages: Dataverse forms on a portal, which is the usual route for cases, since the customer self-service template already carries case submission.⁸
• The Dataverse Web API: A secured endpoint, usually placed behind Azure API Management, for a company that keeps its own website forms and wants full control over the validation.

Please note that Customer Insights – Journeys is a separate app in the Dynamics 365 family, so check whether it is part of the company's plan before the lead forms are designed around it.

3. Email-to-Case

Salesforce Email-to-Case turns an inbound email into a case, and its routing rules decide the queue and the priority from the mailbox it arrived in and the words in the subject.⁹

In Dynamics 365, the support mailbox is connected through server-side synchronization, and the case is created in one of two ways.¹⁰ The automatic record creation and update rules in Customer Service create a case from an email that lands in a queue, with conditions on the sender and the subject.¹¹ On the other hand, when the parsing is more complex than the rules allow, a Power Automate flow reads the inbound mailbox items and creates the case with the correct queue and priority. Either way, the case lands in the queue the agents already work from.

4. Assignment Rules

Salesforce assignment rules are a rule-entry engine. The criteria sit in an ordered list, and the first match decides the owner of the lead or the case.¹² The order matters, and the same order is what makes an old rule set hard to change.

In Dynamics 365, the same job splits in two. For cases, routing rule sets send the record to the right queue.¹³ For leads, a custom plugin with a decision table handles the round-robin or skills-based assignment, because a table replaces the rule order that the sales operations team can read and edit. As such, adding a new territory becomes a row in the table, not a new rule at the right position in the list.

5. Lead Routing

In a Salesforce org, the territory-based and source-based routing usually grows into several parallel Flows, one per region or per campaign, each written by a different admin at a different time.

In Dynamics 365, that logic is consolidated into a single Power Automate flow driven by a configuration table in Dataverse. The flow reads the table each time it runs, so the routing criteria live as data and not as code. That's why the flow itself rarely changes after go-live; only the rows do.

6. Case Escalation

Salesforce escalates a case through time-based escalation rules, which reassign or notify when a case sits too long in a status.¹⁴ When several rules watch the same case, the conflicts stay hidden until a case is missed.

In Dynamics 365, the escalation is re-implemented in parts. A Canvas App manages the escalation criteria, the routing rules stay in Dataverse, custom plugins route the case to the appropriate queue and escalate it against the configured criteria, and the case-form indicators show the agent the escalation status. Power Automate handles the cross-team notifications when a case needs attention. One thing to note is that the native SLA timers do the timing, so the escalation logic no longer has to keep its own clock.

7. Approval Processes with Recall

Salesforce approval processes cover the lead and contact approvals and the case submit-for-approval, and they carry a recall action that pulls a submitted record back.¹⁵

In Dynamics 365, these map to Pre-Operation plugins that implement the submit, approve or reject, and recall actions on the requesting record.² Because the plugin runs before the record is saved, a recall changes the record's state inside the same transaction, with nothing left to reprocess by hand.

8. Screen Flow to Plugin Conversion

Salesforce Screen Flows are guided, multi-screen wizards, and many orgs use them for complex data validation as well.¹⁶

In Dynamics 365, such logic is converted into synchronous C# plugins registered on the Create and Update messages.² Wizard-style guided screens are not the right pattern for backend enforcement logic, whereas plugins execute reliably inside the Dataverse transaction. Simply put, a rule that must always hold belongs behind the form, not in front of the user.

9. Scattered Processes into a Generic Framework

Every long-running Salesforce org carries overlapping point automations. For example, several Flows and triggers that solve similar problems in slightly different ways, usually one per region.

In Dynamics 365, they are consolidated into one configuration-driven framework. It has two parts: a central Dataverse settings table and a single orchestrating plugin or flow that reads the business rules at runtime instead of hard-coding them across dozens of Flows. As such, the experts at Vegacompass say, the framework is designed before the first process is rebuilt; otherwise, the consolidation gets pushed to after go-live, when nobody has the appetite for it.

The Four-Phase Migration Strategy

So far, we have discussed what moves and how each process is rebuilt. However, the order of the work matters just as much, because the sales and service teams keep working while the new platform is being checked. The migration runs in four phases, and each phase produces something the next one depends on.

Below are the four phases of the migration:

• Discovery and Process Mapping: List every Salesforce automation, every security rule, and every integration in the org, and decide for each one whether it is removed, copied as it is, or changed to work on the new platform. Nothing is rebuilt until this inventory is complete. It is the phase that finds the overlapping Flows, and it usually finds more of them than anyone expected.
• Data Model and Security Design: Connect the Salesforce objects, record types, and sharing rules to Dataverse tables, business units, and security roles. In the same phase, write the generic automation plan so that the consolidation of the scattered processes happens before go-live and not after it.
• Build and Parallel Validation: Rebuild the processes in Dynamics 365, then run both systems side by side for a period and compare the outcomes every day. For example, the lead assignments, the case escalations, and the approval decisions. The routing tables are corrected until the two systems agree within an agreed tolerance.
• Cutover and Hypercare: Switch the users over step by step, by business unit or by region, and watch the SLAs and the routing closely in the weeks after each switch. The old system is stopped only after everything has been proven to work in the new one.

One thing most important to realize here is that the parallel run is not a formality. It is the only point in the program where a wrong routing rule shows up as a difference between two systems, instead of as a lost lead or a missed escalation after go-live. That's why the daily comparison continues until the results are stable, and not until a date on the plan.

How long the four phases take depends on the number of automations in scope, the regions to be cut over, and the integrations that must be rebuilt. The program in the worked example below ran over two quarters, with a parallel run of about four weeks per region; a single-region org with fewer automations takes less, and a heavily integrated one takes more. To learn more about the data mapping and the validated cutover, please read our Salesforce Migration Services page.

Step-by-Step Salesforce CRM to Microsoft Dynamics 365 Migration Process

The four phases give the order. The steps below outline the work inside each phase, so that the plan can be checked at every point rather than at the end. In practice, the migration runs through the following ten steps.

1. Inventory every automation, security rule, and integration

Export the list of Flows, Process Builder processes, Apex triggers, assignment and escalation rules, approval processes, and Screen Flows, and put every one of them against the process it serves. Do the same for the sharing rules and for every system that reads from or writes to the org. The count is usually the first surprise of the program.

2. Mark each item as remove, copy, or rebuild

Go through the inventory item by item and decide its fate. A Flow that nobody can explain is removed, a validation rule is copied as a business rule, and three regional Flows that solve the same need become one rebuild. This is the step that shrinks the scope before the build starts.

3. Map the data model

Map every Salesforce object, record type, and field to a Dataverse table and its columns, including the picklist values and the record ownership. Decide what happens to the historical activities and the attachments, because they are usually the largest part of the data, and the decision to keep, archive, or drop them changes the migration effort more than any other.

4. Design the security model

Turn the sharing rules and the roles into business units and security roles in Dataverse. Please note that the two security models are built differently, so this step is designed on paper and reviewed with the sales and service heads before anything is built.

5. Design the generic automation framework

Before any process is rebuilt, design the central Dataverse settings table that will hold the routing criteria, the escalation thresholds, and the approval matrices, along with the one orchestrating plugin and the small set of Power Automate flows that read it at runtime. Every process in the next step is then built on top of the framework, not beside it.

6. Rebuild the processes on the framework

In this step, the team builds the following:

• The Business Process Flows for the sales stages
• The routing flow and its configuration table for the leads
• The plugins for the assignments, the escalations, and the approvals
• The record creation rules or the mailbox flows for Email-to-Case
• The web forms through Customer Insights – Journeys, Power Pages, or the Web API
• The plugins that replace the Screen Flows carrying validation logic

Each of them reads its rules from the settings table, which is what keeps the automation count low after go-live.

7. Migrate the data and rebuild the integrations

Clean and deduplicate the records before they are imported, not after, and load them into Dataverse against the mapping from step 3. Rebuild every CRM integration against the new endpoints, synced in one agreed direction, and document it so that the client's own team can maintain it. For example, the published case study for TDECU (partnered with InnoWise) describes a move from a legacy system to Dynamics 365, and it reports a 95% reduction in duplicate data.

8. Run both systems in parallel and reconcile daily

Keep Salesforce and Dynamics 365 running together for a fixed period per region, and compare the lead assignments, the case escalations, and the approval outcomes between the two every day. Correct the rows in the configuration table until the outcomes match within the agreed tolerance. Every difference found here is a difference the customers never see.

9. Cut over one region or business unit at a time

Switch the users of one region over, keep the daily comparison running for it, and watch the SLAs and the routing closely for the first weeks. The next region follows only after the first one is stable. A phased cutover keeps a routing mistake inside one region instead of spreading it across the company.

10. Hold hypercare and retire the Salesforce org

Hypercare covers the weeks after each switch, when the questions are most frequent, and the fixes are smallest. Once every region is stable, hand over the framework and its documentation to the client's admin team, and only then stop the old org. Retiring Salesforce is the last step, never a milestone on the way.

As you may have already guessed, steps 5 and 8 decide the outcome of the whole program. The framework keeps the business rules in one place, and the daily reconciliation proves that they behave the same way the old ones did. We show both at work in the worked example below.

A Worked Example: A Three-Region Salesforce Org Moving to Dynamics 365

A global enterprise with sales and service teams in three regions ran Sales Cloud and Service Cloud (now sold as Agentforce Sales and Agentforce Service). Over eight years, the org had accumulated more than 40 Salesforce Flows, 12 Apex triggers, and 6 approval processes, while the lead and case volume had tripled since the org was first built. Many Flows fired on the same object for overlapping reasons, and the on-call engineers often could not predict which rule would take effect. Simply put, the automation layer had become hard to follow.

The migration team ran a two-quarter program.

• In the first phase, the team listed all 40-plus Flows and the 12 triggers against the eleven processes in scope, and found that about 60% of them duplicated one another. Different regions had solved the same business need in their own way, at different times, with nobody comparing notes.
• In the second phase, the team started with the automation framework, not with the processes. A single settings table in Dataverse now holds the routing criteria, the escalation thresholds, and the approval matrices for each region, and one orchestrating plugin plus a small set of Power Automate flows read that table every time they run. The Web-to-Lead and Web-to-Case forms were rebuilt on Power Pages, keeping the field validation the Salesforce forms had. The Screen Flows that handled order exceptions were replaced by one C# plugin, so nobody has to launch a guided flow to get an exception checked.

The parallel run lasted four weeks for each region. During it, the team compared the lead assignment and the case escalation outcomes between Salesforce and Dynamics 365 every day. It corrected the routing table entries until the outcomes matched within the agreed tolerance. Only then were the users of that region switched over, and the comparison continued until the results were stable.

Before and After the Migration

The table below shows what the consolidation and the re-engineering changed, measured on the eleven processes in scope:

These figures come from the program's cutover reconciliation logs and post-go-live monitoring dashboards. They are representative of organizations with a comparable volume of overlapping, undocumented automation before the migration, and the actual results vary with the data volume, the integration complexity, and the maturity of the source Salesforce org. Please note that the biggest change is not in the timings. It sits in the first and the fourth rows, where a business rule became a row in a table that a regional operations lead can change without a developer.

7 Best Practices for a Salesforce to Dynamics 365 Migration

At Vegacompass, we say a migration does not fail because the two platforms are different; instead, it fails because the mapping was never designed, and the pieces only looked like they matched.

Below are seven best practices that keep a Salesforce to Dynamics 365 migration on track, whatever the size of the org:

1. Treat the migration as a re-architecture, not a copy

Think of the project as a re-architecture of the business logic and not as a copy of features from one system to another. Every process in this article has a clear equivalent in Dynamics 365 or the Power Platform, but only if the mapping is planned during discovery. A quick check: if the plan lists Flows to be "converted", the mapping has not been designed yet.

2. Inventory every automation before the mapping starts

Count the Flows, the triggers, the rules, and the approval processes against the processes in scope before any mapping begins, and do the same for the sharing rules and the integrations. The duplicates you find at this stage are scope you never have to build. In the worked example above, that was about 60% of the automation layer.

3. Build the configuration-driven framework first

Design the settings table and the orchestrating plugin before the first process is rebuilt, instead of copying each Salesforce Flow one by one. Organizations that start with the framework get the biggest benefits: fewer artifacts to manage, quicker changes, and clearer ownership of the business rules. Those that consolidate after go-live rarely find the time for it.

4. Decide where each rule lives before it is built

A validation becomes a business rule, a backend enforcement becomes a plugin, and a regional threshold becomes a row in the settings table. The mapping decision for each one affects the performance, the maintainability, and the licensing cost, so it is made once, in writing, and not by whoever builds it first.

5. Run the two systems in parallel and compare the outcomes

Compare the outcomes, not the configuration. A parallel run that checks the screens proves the build, whereas a parallel run that compares the lead owners, the escalation times, and the approval decisions proves the business logic. End it when the results are stable, and correct the table rows until they are.

6. Cut over by region or business unit, and keep hypercare running

A phased cutover turns a company-wide risk into a regional one, and the SLA timers on the case form tell you within days whether the routing holds. Hypercare is where the questions of the first weeks get answered before they turn into tickets, and the old org is switched off only after the last region is stable.

7. Audit the Salesforce org before the migration is scoped

The discovery phase is an audit in all but name, and it pays to run it before the licenses are bought and the program is priced. A two-week CRM audit reads the objects, the automations, the data quality, and the license usage, and it ends in a written diagnosis that ranks what to remove, copy, or rebuild. It also answers the question the sales deck usually skips, which is whether the org needs a new platform at all.

On the other hand, if the audit shows that the problems live in the process and the data rather than in the platform, the sensible answer is to fix the Salesforce org and stay, and a platform-neutral partner says so before a migration is sold. At Vegacompass, the consultant who writes the migration plan runs the build with our own delivery team, so the framework promised in the design is the one that goes live. The same person answers for the reconciliation numbers.

Vegacompass: CRM Migration Partner and Microsoft Solutions Partner for Dynamics 365

Since 2014, Vegacompass has worked on CRM and nothing else, which adds up to 12+ years of experience in CRM and digital transformation. We aim to help every organization become the best version of itself through new CRM and AI technologies. We are a Microsoft Solutions Partner for Business Applications, and the published FIMC and TDECU migrations to Dynamics 365 report 98% and 95% fewer duplicate records.

We offer the following CRM consulting services:

• CRM Strategy (Marketing, Sales and Customer Service)
• Revenue Operations Consulting
• CRM Audit & Technical Debt
• Dynamics 365 Implementation and Migration
• CRM Migration
• CRM Data Cleanup
• AI CRM Consulting

Get in touch

A senior consultant reads the note, not a sales rep. After a 30-minute call, you receive a written point of view on what to remove, copy, or rebuild, and it is yours to keep whether or not we go further. An NDA can be signed first.

Talk to a Dynamics 365 consultant today to find out whether your Salesforce org needs the move at all, and what it would take if it does.

References

1. (n.d.). Automate Your Business Processes. Salesforce Help. https://help.salesforce.com/s/articleView?id=platform.platform_automation.htm&language=en_US&type=5
2. (2026). Event framework in Microsoft Dataverse. Microsoft Learn. https://learn.microsoft.com/en-us/power-apps/developer/data-platform/event-framework
3. (n.d.). Integrate other Microsoft products with Dynamics 365 Customer Engagement apps. Microsoft Learn. https://learn.microsoft.com/en-us/training/modules/integrating-office-customer-engagement-apps/
4. (2026). Overview of Microsoft Teams integration. Microsoft Learn. https://learn.microsoft.com/en-us/dynamics365/teams-integration/teams-integration
5. (2026). Understand SLAs. Microsoft Learn. https://learn.microsoft.com/en-us/dynamics365/customer-service/use/customer-service-hub-user-guide-case-sla
6. (2024). Business process flows overview. Microsoft Learn. https://learn.microsoft.com/en-us/power-automate/business-process-flows-overview
7. (n.d.). Generate Leads from Your Website for Your Sales Teams. Salesforce Help. https://help.salesforce.com/articleView?id=setting_up_web-to-lead.htm&type=5
8. (n.d.). Set Up Web-to-Case. Salesforce Help. https://help.salesforce.com/articleView?id=setting_up_web-to-case.htm&type=5
9. (2026). Overview of Customer Insights - Journeys forms. Microsoft Learn. https://learn.microsoft.com/en-us/dynamics365/customer-insights/journeys/real-time-marketing-form-overview
10. (n.d.). Portal apps. Microsoft Learn. https://learn.microsoft.com/en-au/training/modules/power-apps-architecture/7-portals
11. (n.d.). Add Routing Addresses for Email-to-Case. Salesforce Help. https://help.salesforce.com/s/articleView?id=service.customizesupport_configuring_routing_addresses.htm&language=en_US
12. (2025). Server-side synchronization. Microsoft Learn. https://learn.microsoft.com/en-us/power-platform/admin/server-side-synchronization
13. (2026). Automatically create or update records. Microsoft Learn. https://learn.microsoft.com/en-us/dynamics365/customer-service/administer/automatically-create-update-records
14. (2018). Automate Case Management. Trailhead, Salesforce. https://trailhead.salesforce.com/content/learn/modules/service_lex/service_lex_case_manage
15. (2026). Route cases using basic routing rulesets. Microsoft Learn. https://learn.microsoft.com/en-us/dynamics365/customer-service/administer/create-rules-automatically-route-cases
16. (2019). Create a Case Escalation Rule. Trailhead, Salesforce. https://trailhead.salesforce.com/content/learn/projects/set-up-case-escalation-entitlements/create-case-escalation-rule