Many organizations will have multiple versions of Dynamics set up to manage deployments and testing. Typical names for some these environments are:
-
Production (Prod) – This is the main Dynamics environment that is open to the end user. Any changes done to this environment typically went through a testing and release process prior to being deployed.
-
User Acceptance testing (UAT) or Quality Assurance (QA) or Sandbox– These environments are typically used for testing and to verify the quality of the application and find any issues that need to be addressed prior to moving over to production.
- Development (DEV) – This is where new customizations are developed. This environment should resemble the production environment as much as possible to prevent issues where the software acts differently on production.
There may be more or fewer of these environments and they may have different names and purposes depending on the deployment processes of your organization.
WARNING: When you import a copy of your production environment into your Sandbox, all connection details remain the same as in production. If plugins are still enabled in Sandbox, anything deleted from the sandbox will be deleted from the production account on our cloud and will be irrevocably inaccessible from the production Dynamics environment.
Common questions regarding managing multiple Dynamics environments with Click
-
Do I need to register each environment?
If you want each environment to have a functional integration with Click (ie, so you can send emails or design forms and surveys) you will need a different solution for each one. However, if you don’t need to use the Click features in your non-production environment, you can import your production solution file into the non-production environment(s). This is useful for migrating the Click entities between environments, testing customizations to a Click entity or referencing a Click entity in a customization.
-
What is the impact of refreshing a test environment with a copy of our production Dynamics database?
If you have registered separate solutions for each environment: Many of the Click records in Dynamics reference what is called the Account Key. This is a unique identifier in each solution. If you restore a copy of your production Dynamics database to a test deployment, you would then need to import the solution that was provisioned for your test deployment on top of the existing one in order to overwrite the Account Key that is embedded in the Dynamics database. It is always recommend to import the Click Solution file for the correct environment after a refresh to ensure the site map is correct. Additionally you may need to edit the sitemap to put in the correct Account Key. Instructions can be found here.NOTE : As of Click version 8.2.0 in CRM 2016 environments, it is now also possible to update the Account key by going to Settings > Solutions, opening the Click solution and entering the Account Key, Token and Region on the Configurations page.
-
What about Email Templates and Web Content (Forms, Surveys, landing pages, subscription pages)?
Every registered environment has its own storage on the Click servers for the hosted web content HTML. A combination of the Account Key and record ID (or GUID) from Dynamics is used to link the record to the current web content. This makes it impossible to refresh the actual HTML content for Web Content records between environments. You will not be able to access the designer for Web Content if it was designed in a different environment. It would need to be recreated manually. (You can export Email Template records and import them into a different Dynamics deployment of the same version of Dynamics by using our Export/Import tools, found on the ClickDimensions Settings page in Dynamics.)
-
How do I move a Campaign Automation from one environment to another?
You can now use the same export/import tool mentioned above: https://support.clickdimensions.com/hc/en-us/articles/115001168814-Export-and-Import-ClickDimensions-Records