Comments on: CRM ALM with Click Dimensions – My findings working with Click Dimensions/2015/10/12/crm-alm-with-click-dimensions-my-findings-working-with-click-dimensions/Sharing my work and study experience with technologies.Tue, 19 Apr 2016 23:32:22 +0000hourly1http://wordpress.com/By: Andre Margono/2015/10/12/crm-alm-with-click-dimensions-my-findings-working-with-click-dimensions/#comment-261Tue, 19 Apr 2016 23:32:22 +0000/?p=928#comment-261In reply to Neil Benson.

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).

]]>By: Neil Benson/2015/10/12/crm-alm-with-click-dimensions-my-findings-working-with-click-dimensions/#comment-259Tue, 19 Apr 2016 06:49:46 +0000/?p=928#comment-259Hi 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?

]]>