Creating Icons for Dynamics CRM 2011

 

***STOP PRESS***

If you follow my tweets you will have seen the odd mention of a session at the MVP Summit regarding the new polar data centers Microsoft is rolling out. I am still under the embargo/NDA from Summit (and probably should not have mentioned as much as I have) but have finally been given the green light to talk about it now that Convergence is finished so this will be coming out next week. Serious game-changing technology on many levels and very exciting for Azure and CRM Online customers. Not to be missed. Now back to regular broadcasting…

The Problem

One of the key strengths of Dynamics CRM is the ability to go beyond the traditional domains of salesforce automation, case management and direct marketing. To give an example, the last two projects I worked on involved:

• Contract execution for an international transportation company i.e. sourcing the goods, sourcing the transport and ensuring all customs regulations were followed
• Management of the committees and the associated projects in developing international standards for industry

Both of these were pure CRM systems i.e. minimal third party add-ons and required minimal code. Neither fell into the classic baskets for CRM systems but this is the norm for Dynamics CRM.

But I digress, as this is not a blog post about xRM. An inevitable consequence of going outside the traditional areas is you must create additional entities to hold the data. Entities are the ‘record types’ or, for the more traditional of us the additional database tables to hold different kinds of data (it is not as simple as one entity = one table in Dynamics CRM but the analogy is sound).

Creating the entity is easy, as is linking it to existing record types in CRM. You simply hit the new button and give it a name.

One of the trickier aspects is updating the icons for the new entity. Sure, there is the ‘Update Icons’ button on the top of the entity screen but what then?

Well the screen that pops up highlights the problem nicely.

For any given entity we need to create:

• A PNG file of 16x16 pixels
• An ICO file of 32x32 pixels
• A PNG file of 66x48 pixels

but there is nothing, directly in the product, to help us do it.

The Solution (almost)

For version 4, Tanguy (an all-round great guy) wrote an excellent article on how to use the Microsoft Demonstration Tool to automatically generate the icons and upload them to CRM. In fact the article was so good, these guys ripped it off a year later

Despite our German plagiarists publishing the article under a 2011 blog, the tool does not quite work for CRM 2011. While you can connect the tool to an on-premise implementation, it will not connect to an online one. Also. while you can connect, you cannot directly upload.

So what do you do?

Well, assuming you have access to an on-premise implementation (perhaps you have a copy of the CRM demo VPC from a friendly partner) you can still create the icons.

First of all, download the Demonstration Tool program, run the exe and click the link at the top to connect.

The box that pops up asks for the usual login, password etc. Once in, click the Icon maker icon to take you to the icon maker page.

Click on the first Select Image… and add in a picture. Then click the ‘Use for all icons’.

The image above is taken directly from Tanguy (saved me firing up my VPC). He has chosen to click the ‘Add Background’ box as well. I generally don’t but it is up to you.

If this was CRM 4, at this point you would click the ‘Publish to CRM…’ load up the icons and congratulate yourself on a job well done. No such joy for us CRM 2011 folk. We need to click the ‘Save…’ button. The usual file save box opens up and while it will give all indication that it is just saving a png file it will, in fact, save three files, with semi-meaningful names (‘application’, ‘outlook’ and ‘form’), for manual uploading to CRM.

Loading up Icons

CRM 2011 treats images as Web Resources. So, in order to load an image up for our entity, we must add it as a Web Resource. Generally I do this on the fly. So firstly, go to the entity and click on the ‘Update Icons’ button. Now click on the first lookup.

Click the ‘New’ button to add a new Web Resource. Click OK a lot and you will have your first image in CRM. Rinse and repeat for the other two lookups and you are done.

Conclusions

The process for adding custom icons to CRM has not changed significantly, from memory, since version 3 so it is a little clunky. If Dynamics CRM was getting a performance review from its boss, this would fall under the ‘needs improvement’ column (and I am sure it is on the list back in Redmond). However, assuming you have access to an on-premise install, you can generate the required icon files relatively painlessly with the version 4 Demonstration Tools. Download it and go from to . If you feel Microsoft should invest some time in improving the icon updating experience, you can also drop by at http://connect.microsoft.com and add in a request. This list is the driver for new features in the product so have your say.

Using An ‘OR’ Condition In Workflows

The Problem

One of the problems with workflows is that,while you can group conditions with an OR in Advanced Find, you do not have the same ability within workflows.

Here are the advanced find grouping buttons.

Here is the workflow box for a ‘Check Condition’ step.

We can list multiple conditions but these are automatically grouped with an ‘AND’ clause i.e. all must be fulfilled.

This issue has come up in the forums in the past and, usually I recommend the creation of two workflows: one for each condition. While this approximates an ‘OR’ it is a lot of work.

The problem with this solution is we now have two workflows to maintain which means more overhead.

An Alternative Solution

De Morgan’s Law tells us that ‘A OR B’ is logically equivalent to NOT (NOT A AND NOT B). So how does this help us?

Well, to deal with the first ‘NOT’ we use the ‘Default Action’, which gives us an ‘Otherwise’ to our ‘If-Then’

Therefore, if we say ‘if (NOT A AND NOT B) then do nothing otherwise do x’ we have a winner.

So, in practice, let us say we want the workflow to trigger if either of one of two tickboxes are ticked. For an advanced find it is east to find records where Tickbox A or Tickbox B has been ticked.

For our workflow it is going to read thus:

If we trigger this off of the two fields changing, if neither of the fields are ticked, nothing happens but if either or both are ticked our action happens, which is what we want.

Doing the Maths

If you have a more complex problem, this is how to approach it.

First of all we have De Morgan’s Law: A OR B = NOT (NOT A AND NOT B)

Let us define our logical tests:

A: Tickbox A = Yes
B: Tickbox B = Yes

Therefore:

NOT A: Tickbox A = No
NOT B: Tickbox B = No

So Tickbox A = Yes OR Tickbox B = Yes is equivalent to NOT (Tickbox A = No AND Tickbox B = No) and this is expressed as we saw above using an if-then-otherwise step.

Conclusions

Using this technique, while a little harder to read (although the comment line can help) we maintain just one workflow, saving on future administration.  The technique is also applicable to any condition which there is a straightforward ‘opposite’ version of and can be extended to multiple attributes, not just two, without having to resort to creating multiple, mostly identical workflows.

Triggering a Workflow off a Field’s Initial Population

The Problem

When triggering workflows, there are seven options:

• When the record is created
• When the status of the record is changed
• When the record is assigned (ownership changes)
• When a field on the record changes
• When the record is deleted
• Manually (an on-demand workflow)
• As part of another workflow (child workflow)

This covers a wealth of scenarios. However, there are times when we need more. Recently I worked on a project where we needed to trigger off the initial population of a field. The company was, in essence, a courier company. Customers booked international deliveries and, while the bookings were entered into the system when taken, it was only later that my client knew which plane was taking the goods.

Once the details of the plane was entered in the system, escalation checks needed to be put in place to ensure a paperwork was completed on time, deliveries reached their destination on time etc.

The obvious choice was to trigger off a field change but, if the plane details changed prior to take-off, this would trigger two escalation workflows as it is not possible in a workflow to check what the value was prior to field population. If the details changed a number of times, suddenly users are receiving multiple notifications for the same delivery. This was undesirable.

The Solution

The first option in dealing with this scenario is to use a check box on the record. When the workflow is first triggered, the tickbox is ticked and future workflows, checking for the tickbox no longer fire. Another related option is to have a field keep a copy of the previous value, managed through workflows. I outline this approach here.

This would have worked but there were a number of date fields that I needed to trigger off (about ten in total) and the overhead of adding another ten checkbox fields or adding fields and workflows was a bit high for me.

In the end I settled for a different approach; instead of using the ‘field change’ event, which can be triggered multiple times, I used the ‘record creation’ event which will only ever trigger once. The screenshot below shows the trigger on the ‘Vessel ETD’ field; the plane’s estimated time of departure (ok, so the project is on a v4 system, but the approach also works 2011).

Here we are saying when the delivery contract is entered into the system, fire the workflow and then wait until the ‘Vessel ETD’ field is populated. When this happens, fire a number of ‘checks and measures’ workflows.

These child workflows then kick in. Here is one of them:

In this case, once populated, we check the contract is a parent contract (the system allows for subcontracts on the same flight contract), double check the field contains data (not really needed) and then it sets up a reminder a couple of weeks before departure.

The advantage of this approach is that we guarantee that the workflow will only trigger once and, if we have a number of checks and measures running off of the same field, it is quite easy to manage this through the use of child workflows stemming from the one trigger workflow.

The disadvantage of this approach is, if there is significant time between the creation of the record and the population of the trigger field, we have a workflow in a waiting state gobbling up processor cycles. This is more of an issue if we have a high volume of contracts, which I did not have in this case.

Conclusions

If you are needing to trigger off the initial population of a field but do not want to fire the same workflow when the field gets updated there are a few approaches with workflows before resorting to code. Using a check box can work but can be tricky to manage and adds the overhead of a bunch of fields which are just used for workflow management. Adding a mini-audit function can also work but requires additional workflow and fields to be added to the system, again adding to workflow management.

By triggering off of the creation of the record, and waiting for the field to be filled in before acting, we create an intuitive system with minimal overhead in terms of fields or workflows which can be easily adjusted as the processes of the business evolve.