Prepare for your Dynamics 365 Sales deployment
Before you configure Dynamics 365 Sales, a little upfront planning goes a long way. Three areas are worth thinking through before you start: your licensing model, your technical prerequisites, and how you'll manage the application lifecycle across environments. Getting clear on these early helps you avoid costly rework later.
Evaluate licensing
Dynamics 365 Sales is available in several licensing tiers: Sales Professional, Sales Enterprise, and Sales Premium. Each comes with a different feature set. The right license for your organization depends on your team size, the features you need (including AI agents and Copilot capabilities), and how you plan to grow.
Tip
For details on what's included in each license tier, Copilot Studio credit entitlements, and how to assign licenses to users, refer to the Dynamics 365 Sales licensing guide and the Licenses and storage FAQ.
One thing worth noting: your license determines which out-of-the-box app you use. The Sales Hub app is available with Sales Enterprise and Sales Premium licenses, while the Sales Professional app is available with the Sales Professional license. Both apps may appear in your environment, but you should only use the one included in your license.
Evaluate system prerequisites
Dynamics 365 Sales apps are model-driven apps built on Power Apps, which means system requirements are relatively lightweight for end users. What matters most is browser and operating system compatibility, network connectivity, and regional availability.
| Area | Requirements |
|---|---|
| Operating systems and browsers | Supported operating systems and browsers follow Power Apps requirements. See System requirements for Power Apps. |
| Network | The embedded Teams dialer uses Azure Communication Services. See network requirements for Azure Communication Services. |
| Storage | Azure or Teams storage is required for storing call recordings. |
| Regions and languages | See the Infrastructure and availability PDF and the Language availability report. |
Note
Sales Premium features are only supported in specific regions and languages. Check the regional and language availability documentation before planning your deployment.
For full installation instructions, see Install Dynamics 365 Sales apps.
ALM in Dynamics 365 Sales
Application lifecycle management (ALM) describes how you manage changes to your Dynamics 365 Sales configuration over time—moving from development, through testing, and into production in a controlled, repeatable way. Planning your ALM approach before you start customizing is one of the most important things you can do for a successful deployment.
Environments
In Dynamics 365 Sales, an environment is a container that holds your data, app configuration, and customizations. A typical deployment uses at least three environments:
- Development — where you build and test customizations
- Test (UAT) — where stakeholders validate changes before they go live
- Production — the live environment your sales team uses every day
Defining your environment strategy early matters because it shapes your security model, your deployment process, and your costs. Changing it later is difficult and expensive. Key questions to answer upfront:
- What are your data residency and compliance requirements?
- Which teams (developers, testers, trainers) need access to which environments?
- Will your deployment span multiple regions or business units?
Learn more in Plan your environment strategy for Dynamics 365.
Solutions
Customizations in Dynamics 365 Sales are packaged and transported using solutions. A solution is a container for components—tables, forms, flows, security roles, and more—that you want to move between environments.
There are two types of solutions:
- Unmanaged solutions are used in your development environment. You create and modify components in an unmanaged solution, then export it as a managed solution to deploy downstream.
- Managed solutions are deployed to test and production environments. Once imported, managed components can't be edited directly—you make changes in the development environment and redeploy.
This separation keeps your test and production environments stable while giving developers freedom to iterate.
A few best practices to follow from the start:
- Create a custom solution publisher with a meaningful prefix (for example,
contoso) to avoid naming collisions if you ever install third-party solutions. - Check all customizations into source control as unmanaged solutions.
- Treat managed solutions as build artifacts—generated from unmanaged, not edited directly.
Learn more in Solution concepts for ALM.