This series will focus on using best practices to improve your company’s use of the Microsoft Power Platform, including Dynamics 365 Customer Experience (formerly CRM).
Some organizations start their journey with Microsoft Power Platform, or other business applications, using minimal governance or without giving proper consideration to best practices. However, as usage of the system grows and the organization comes to depend on it for business-critical functionality there will come a time where ignoring these concerns can increase both the cost and risk of further customizations.
Multiple Environments
One of the simplest improvements that can be made to your system is to establish multiple Environments. An environment is simply an isolated and independent instance of your system. Having multiple environments allows changes to be made in one environment without impacting the others. Most non-trivial business systems use separate environments to accommodate certain groups that each need to use the system for specific purposes without impacting the organization’s primary environment (generally called Production). Common examples include a group of developers creating new functionality or business analysts performing user acceptance testing.
Those of us who have worked with multiple environments for many years may wonder how an organization would ever find itself with only ONE environment. There are several common scenarios where this could happen. Organizations that are currently using an older On-Premise Microsoft Dynamics CRM system may have only installed a single environment. Or perhaps an organization started using Microsoft Dynamics 365 (online) as a small prototype and experienced rapid growth. Both of these cases represent situations where having only a single environment is understandable, but these are also good candidates for taking advantage of the benefits that come from an updated environment strategy.
Most subscriptions to the Microsoft Power Platform include multiple environments as part of the subscription cost. Provisioning a new environment is a trivial task that can be performed by a Dynamics 365 Administrator.
Having multiple environments empowers your organization to mitigate the risks that can come from making changes directly in your one-and-only Production instance. Developers can safely modify existing screens in the Development environment without impacting the Sales group working to close a deal in the Production environment.
In addition to defining which environments are needed and their respective purposes, organizations will also want to consider when and how to migrate system customizations from one environment to the next. These are almost always applied in a specific order, with Production as the last environment to be updated.
The number of environments and their respective purposes will depend on the unique needs of your organization, including the number of people contributing customizations, your approach to testing, and the geographic regions where your Production instance or instances are hosted.
For systems based on the Microsoft Power Platform there is one additional concern that needs to be defined for each environment: whether to use Managed or Unmanaged Solutions. Exploring the details of these types are beyond the scope of this post. But as a general rule, Unmanaged Solutions are editable and must be used during development. Managed Solutions are read-only and used to deploy changes for Testing or to Production.
Common Environment Types
Here is an overview of the most common environment types:
Production
Production, as one might expect, is the final environment, where the organization's actual work is performed. This should be the most stable environment and it should have security restrictions to only allow changes to be applied by the designated System Administrators. Customizations should not be made directly to the Production environment. Rather they should be applied following the Organization’s migration strategy - generally using Managed Solutions that were exported from the Development environment and verified in the Testing environment.
Testing
Testing (or User Acceptance Testing) is used to test and validate customizations before approving their release to Production. All users (including Developers) should have only user-level access, allowing them to test the behavior of the system in a way that closely resembles how it will perform in Production. Organizations may have no Testing environment or multiple Testing environments, depending on their unique needs and strategy.
Development
Development is where new functionality will be created and tested by system customizers or developers. Most business users will not be allowed to access Development, but most Developers will have full system administrator permissions. This environment will be the most frequently changed and the least stable. All new Solutions must be created as Unmanaged, by definition. Once the changes are complete and ready for further testing the changes can be deployed to the next environment.
Common Environment Strategies
Here are some examples of common Environment strategies:
Development / Production
Development / Production - very small organizations can work effectively with only these 2 environments. Testing to validate the changes can be performed in Development.
Development / Testing / Production
Development / Testing / Production - the most common approach for organizations large enough to have separate groups for development and testing.
Development / Integration Testing / User Acceptance Testing / Production
Development / Integration Testing / User Acceptance Testing / Production - the largest organizations may have the need to perform an additional layer of testing and validation by their IT group in Integration Testing before engaging business testers in the User Acceptance Testing environment.
Summary
In summary, following best practices for business-critical systems will lower both cost and risk. One of the best practices is to establish multiple environments to provide system instances for development and testing. The number of environments and their target users will depend on your organizations’ size and specific needs.
