CRM ALM with Click Dimensions – My findings working with Click Dimensions

Andre Margono Microsoft CRM

I’m currently working on a project that implementing Click Dimensions as part of the solution for email marketing and we are using Agile methodology in our project.

As part of the project ALM requirement we have 4 environments (Dev, Test, UAT, Prod) to maintain. And given Click Dimensions solution is unique across instances, we found it is a bit tricky to do development and deployment across environments. Below are the questions that we had during the project:

How to deploy a customized sitemap/ribbon? Some cases that we encountered:

  • We developed custom rule to hide/show “Send” button based on security privilege (only user with some specific privilege could send the emails), we modified the “Send” button to have the display rule, however when we deploy our solution to a different environment (Dev to Test for example), the “Send” button is referring to the originating environment account key.
  • We made some changes to the sitemap, as we want some of common ClickDimensions entities to be available in the other location in sitemap to provide better navigation for the users. Now when we deploy our solution to a different environment, ClickDimensions Settings page is broken, as it is expecting the previous environment account key.

The solution

keep-calm-and-go-back-to-basics

“Back to basics” – ClickDimensions is an xRM solution that built natively on top of Dynamics CRM. So, behind the scene it is a native CRM solution (ref: https://msdn.microsoft.com/en-us/library/gg309639.aspx). And after spending a fair bit of time comparing the DEV and TEST solutions, I can conclude that the only differences that these solutions file are:

  1. Location of Click Dimensions server (depending to the data centre of your Click Dimensions instance: US, EU or AU).
  2. Account key: unique across instances (DEV, TEST, UAT and Prod).

Note: It is adviseable to note down these keys for future reference.

So, to ensure my solution file, that is referring to ClickDimensions’ customisation, to be able to be imported at the target environment without any problem. Once I’ve exported the solution from my DEV environment, I just simply need to replace the difference to point to the target environment by unzip the solution file, edit the customization.xml, find and replace the references (e.g: Account Key, use any text editor such as notepad++ to replace all recurrence of DEV account key to the target environment’s account key).

Now, I’m able to import my solution to the other environment without any problem. It might require a bit of due diligence, but at least we could still following our project methodology.

HTH!

2 thoughts on “CRM ALM with Click Dimensions – My findings working with Click Dimensions”

  1. Hi Andre, thanks for your post. The way I’ve worked with these kinds of environment-specific issues is to create a custom entity called Variables which has two fields: Name and Value. Now in code, we can detect which CRM environment we’re running in, then use the Value of the appropriate Variable. Would that have worked for you?

    Reply

    • Hi Neil, thanks for your comment. I usually have this kind of entity to store variables/settings that is specific to the solution most of the time it would be key-pair structure. And I would consider that as a good practice in creating solutions around reference data.
      Meanwhile this post is about on what I encountered with Click Dimensions deployment, where they generate a unique account key from their side for each CRM environments that we have. So our DEV, TEST and PROD account key will be different and they are embeded in their custom buttons/links where it might be referred in our solution (especially if we include the sitemap/ribbon customisation in the solution).

      Reply

Leave a comment