Differentiating between Test and Production Environments

Being able to distinguish between a test and production environment can be quite important. Often times you may be working in both simultaneously with the obvious potential to get mixed up which may cause undesired results.

This is easy enough to deal with and there are a number of simple solutions out there that involve making an unsupported changes to the CRM style sheets. And if this works in your case then great.

However one of the benefits of multi-tenancy (the likes of which CRM 2011 provides more so than 4.0 since the latter's professional edition did not allow for multi-tenancy whereas it is accomodated in the corresponding 2011 version) is that it is very easy to set up a test or development environment. The best case scenario is to always have a test or development environment on a completely separate server. If that is the case then the method of differentiation referenced above works fine. But smaller CRM installations do not often have the benefit of the additional hardware and therefore having the option of creating another environment by just creating a new organization on the same server is a good solution.

In this case - as far as I'm aware - using the method of differentiation listed above will not work since all the organizations run on the same physical hardward and therefore style sheet edits will affect all organizations running on that server.

Furthermore if you are using CRM Online you obviously cannot make such changes so that option is not available. That is unless you decide to create an on premise test environment in this case. However if you decided to have an online test environment then you are going to be out of luck. It would be nice if Microsoft provided a few different skins for CRM that could be selected in the system settings as a way of dealing with this issue. I'm guessing it won't be very long until we have that option (it kind of jives with Microsoft's latest rollup theme of CRM Anywhere... at least to me).

But until then, one way of getting round this is to use the Application Ribbon to publish a very conspicuous icon that will appear on every form, home page, view, and advanced find form as illustrated below.

This approach is not only supported (as opposed to the unsupported CSS edit) but it can be applied in all implementation scenarios.

The downside to this approach is twofold:

1. If you have customized the Application Ribbon as part of your installation then you would have to merge any changes into your test environment. Conversely if you enhanced the Application Ribbon in your test environment you would need to remember to remove these icons before publishing to production. The Application Ribbon is arguably a relatively seldomly used area of customization (as it's globabl in nature - you are more likely to want to make ribbon changes in specific entities which you would do in the entity customization) so it might not affect you. Even if it has been customized - unless it contains critical functionality or functionality that you are immediately testing or enhancing - it may not be necessary to always be completely up to date in your test environment.
2. Whenever the test environment is refreshed you will need to re-import this solution as a post refresh step. Not a very onerous task (unless a merge is necessary as per #1).

If the issues listed above do not affect your installation, then this approach might work for you. You can download this solution from here. Use at your own discretion.