When CRM Analytics is selected as a Business Intelligence application for data visualization, a common question always arises:
Should we develop in Production or in a Sandbox?
In this post, we will cover advantages and disadvantages of using Production and Sandbox for any CRM Analytics development projects, and also cover the Admin responsibilities when it comes to managing CRM Analytics assets.
The Case for Using Production
CloudKettle’s recommendation is to use Production for any BI Project development in CRM Analytics. This is especially true when the CRM Analytics instance is brand new and no prior work was done in the application. The main benefit of working in production is that you will always be working with a full picture of your Salesforce data. This is very important for QA and UAT purposes.
When we talk about developing in production, people often ask: but what if we don’t want users to have access to our assets while they are in development? The good news here is that CRM Analytics allows you to build custom apps and fine tune who has access to them.
CloudKettle recommends that a dedicated development app be created with access restricted to the Users who will play a part in the development. After development and testing is complete, assets can be moved to the shared app where a wider range of Users can access and begin the UAT process. Working directly in production gives access to the full Salesforce data and will make the QA process easier for checking if CRM-A assets meet the requirements of a User Story. Developed Dashboards can also be rolled out to business users very quickly.
When to Use a Sandbox
On the other hand, if there is a requirement to develop in a Sandbox, one should consider using a full copy sandbox to have the most recent version of production data to work with. After the Dashboard and other assets are fully developed and approved by stakeholders for deployment to production, there are two options: Using JSON to migrate the assets OR using Change Sets.
Migrating using JSON
Migrating using JSON files and JSON code for Dashboards is fast compared to a migration using change sets. But JSON migration does not migrate the customization to fields, conditional formatting etc. done in the dashboard design layer to production. This customization, conditional formatting etc. must be manually implemented after your migration to production is complete.
Migrating using Change Sets
Change sets will take a little more time than a JSON migration, but will migrate all assets and the customizations to production. One can weigh the time required for manual customization using JSON migration vs time taken for migration using change sets, and decide the best option to use for migration. However in most cases CloudKettle recommends using Change Sets when developing in a Sandbox.
Quick Tips and Hints
Here are a few other items to consider when migrating:
- After migration, the order of operations for local sync, recipes and/or data flows has to be set up in production for the first time. If the same assets are migrated with changes from Sandbox any time after the first migration, the schedule will be retained in Production.
- If the development is done in Sandbox and a Sandbox refresh is due, it is important to either move the assets to another sandbox or take backups of the assets. This is to ensure the development that only exists in Sandbox is retained and not overridden by refresh from Production.
- If the change set method is the process used for migration, then it is recommended to migrate the assets to another Sandbox while the refresh happens. Once complete, migrate the CRM Analytics assets back into the sandbox and continue development.
- If the JSON files and JSON code are used for migrations, then it is important to take backups of this code regularly and note all customizations and formatting done in the dashboard design layer. This way, after Sandbox refreshes these backups can be used for updating assets in the Sandbox. Customizations are to be manually added post JSON backup upload.
Overall, it’s best practice to document each step of your development lifecycle. CRM Analytics offers good documentation tools, including the description fields in recipes and dataflows, version history in recipes and dataflows, and the version history on dashboards. Irrespective of development in production or sandbox, having a well documented process will make it easy to support and administer the CRM Analytics application across the organization, and help improve your organization’s overall Business Intelligence Maturity.
Have questions about your own CRM Analytics implementation, or want to discuss Business Intelligence best practices? Get in touch! We’d love to share some of our ideas with you.
