Archive for the ‘Dynamics CRM 2011’ Category

Every time I have to do something with activities in CRM it ends up taking way longer than expected. Unlike most entities in CRM, activities have a lot of unusual relationships and field types, not to mention all the behind the scenes processes which tend to not like when you introduce your own custom logic.

In this blog post I want to simply look at party list fields, and how to read and update the field values.

An activity partylist field is like the To, CC, BCC fields on an email – they can contain multiple entity references, and they can also contain different entity types (contact, user etc). When we for example do a retrieve on the email entity using the SDK, the ‘to’ field is of type EntityCollection.

If we break this down, each Entity in the collection is an ‘activityparty’. The Activity Party entity is the intercept entity for all the activity party list fields. Activity parties are not only used for the party list fields however, they’re also used for the regarding and appointment organizer etc.

So what fields do we get from each of the activity party Entity objects?

If we break it down, it has 3 main fields. The partyid, which is the actual EntityReference to the contact, user, account etc which is being referenced. The addressused, which is only really used when emails or appointments are tracked from outlook; this is the actual email address of the recipient that CRM used to match it to a record. Finally there is a field called ispartydeleted, which simply tells us if the record behind the activity party has been deleted; since CRM does not delete the activity party, nor does it clear the partyid, this is the only way of knowing that the record actually exists (without trying to retrieve it or something).

Entity email = _sdk.Retrieve("email", emailId, new ColumnSet("to"));

EntityCollection to = email.GetAttributeValue("to");
if (to != null)
    to.Entities.ToList().ForEach(party =>
        EntityReference partyId = party.GetAttributeValue("partyid");
        bool isDeleted = party.GetAttributeValue("ispartydeleted");
        string addressUsed = party.GetAttributeValue("addressused");

        // Do something...


When you’re creating an activity party, you need to set the partyid and/or the addressused. You must set at least one, and they cannot be null – so make sure not to add it to the property bag if there’s no value. CRM will throw an error if neither attribute is set, or if you explicitly set one of the attributes to null.

If you specify an addressused and not a partyid, the activity party will be ‘unresolved’ on the activity. It will display as just the email address, with a red font.

You don’t need to do an SDK Create or Update request on activity parties, just update the EntityCollection and add it back into the parent activity ‘to’ or ‘cc’ field etc and then update/create the activity – CRM will take care of creating or updating the parties.

If you’re copying activity parties from one activity to another, or from one partylist field to another, make sure to remove the activitypartyid from the Entity objects, as these are unique for each party. Simply leave this field out of the attributes list so that CRM will create a new activity party.

// Create a new activity party linked to a contact
Entity party1 = new Entity("activityparty");
party1["addressused"] = "";
party1["partyid"] = new EntityReference("contact", contactId);

// Create a new unresolved activity party
Entity party2 = new Entity("activityparty");
party2["addressused"] = "";

// Create a new EntityCollection and add the 2 parties
EntityCollection to = new EntityCollection();

// Create an email with the EntityCollection
Entity email = new Entity("email");
email["subject"] = "Test Party Lists";
email["to"] = to;



If you want to delete an activity party, simply remove it from the EntityCollection. CRM will take care of deleting the activity party record behind the scenes. This example removes the unresolved and deleted parties from the ‘to’ field.

Guid emailId = new Guid("1EFCBB18-F3B6-E411-80BA-00155D048D48");
Entity email = _sdk.Retrieve("email", emailId, new ColumnSet("to"));

EntityCollection to = email.GetAttributeValue("to");
if (to != null)
    to.Entities.ToList().ForEach(party =>
        EntityReference partyId = party.GetAttributeValue("partyid");
        bool isDeleted = party.GetAttributeValue("ispartydeleted");
        string addressUsed = party.GetAttributeValue("addressused");

        if (isDeleted || partyId == null)

email["to"] = to;


In Dynamics CRM every now and then users may encounter errors like the one below. These are typically random errors with Microsoft scripts that usually do not affect any functionality.

We’re prompted with the option to ‘Send Error Report’ to Microsoft so they can fix the bug if enough reports of the same issue come through, or we can click ‘Don’t Send’ and it will just close the dialog box and ignore the error. This dialog can be useful for customizers, but it is unnecessary to show to general users.

Each user can define their preferences for displaying these error messages in their Personal Options under the Privacy tab. By default it is set to ask us every time whether to send an error report or not. We can also select to automatically send the errors, or to never send the errors. Usually this is changed for everyone to automatically send or never send so that the dialog boxes do not show up.

What some people don’t know, is that we can define these preferences at a global level, so that each user doesn’t need to go into their personal options to make this change, and new users won’t need to see those popups by default.

To change this setting globally, go into System Settings, Administration, and click on Privacy Preferences.

On the Error Reporting tab, we can tick the box to specify the error preferences for all users, and then select whether to automatically send, never send, or prompt every time.

Once this change has been made, users will no longer see the Privacy tab in their personal options, and they will not be able to change this setting. Any new users that get created, as well as all existing users, will have these preferences automatically.

One thing to note is that as this is not a part of System Settings, you cannot deploy these preferences in a solution, so you’ll need to configure this in each CRM system.

Watch as I present at the March Auckland xRM/CRM User Group on configuring the CRM 2011 Online Yammer Integration.

This live presentation includes:
– What is Yammer?
– Why you should use Yammer
– What you need before performing the Integration
– Configuring the Yammer Integration in CRM
– Configuring System Post Rules
– Examining the Integration and Record Walls
– Live Demo of setting up the Integration

Why use Yammer:

Getting Yammer Enterprise: If any issues, contact Aaron Zukoski, Phone: +61 040 999 8169.

When posting an update on the Yammer feed from a CRM 2011 record, you may have noticed the ‘Post to’ defaults to ‘My Colleagues’.

Post to My Colleagues

You can change this selection to a specific group within Yammer, which means the update will only be posted to that group, whereas if you leave it as the default ‘My Colleagues’ the update will be posted to the whole of Yammer for anyone to see.

Even if you have selected a Yammer Group ID to control conversation access in you Yammer Configuration settings, the wall posts will still default to My Colleagues. Unfortunately at this time even if you change the ‘Post to’, it will not remember the selection for next time, so you would have to do this every time you post on a record wall.

Yammer Configuration

If you have selected a Yammer Group for CRM to post to, you will notice that any wall posts that are posted to ‘My Colleagues’ do not show up in the “What’s New” area of the CRM workplace, as this only shows Yammer posts within the selected Group. Since the CRM wall posts are defaulted to ‘My Colleagues’, these posts will not appear in the Yammer group.

Hopefully this is patched in a future update, but until then make sure if you’ve configured your integration to use a specific group that users are actually posting to that group.

The alternative is to not select a Yammer Group to post to, so the “What’s New” area of CRM will display all Yammer Posts (including those posted to ‘All Colleagues’). This would mean you don’t need to worry about changing the default ‘Post to’ on wall posts.

In Dynamics CRM 2011 Rollup 5, Microsoft introduced multi-series charts. Basically this means you can now graph 2 or more fields side by side so you can compare these values visually. One example of this would be Opportunities Est. Revenue vs. Actual Revenue, grouped by Owner. Using this example, we would have one Category (Horizontal) axis; Owner, and 2 Series (Vertical) axis; Est. Revenue and Actual Revenue. When the chart is previewed, the sum of both values for each user will be displayed side by side, to see which users are under or over estimating.

We can see in the image above the chart showing Est. Revenue vs. Actual Revenue, grouping by Owner. In the chart designer, we have defined the revenue fields as Legend Entries (Series), and the Owner as the Horizontal (Category) Axis.

You may have noticed in the first image, that there were 2 different scales, one for each of the series. In this case, the Est. Revenue scale goes up to 300,000 and the Actual Revenue scale to 200,000. This means the values being compared are not a direct comparison, as you can see in the first column the Actual Revenue which appears more than the Est. Revenue is actually less.

Fortunately we can modify the chart XML to allow the chart to use the same scale for both values. First you need to export the chart, which you can do in one of the following ways:


Expand and view the chart you want to export from an entity grid view. On the Charts tab of the ribbon, click the ‘Export Chart’ button. NOTE: To re-import the chart use the ‘Import Chart’ button above.


Select the chart from the Customization area/Solution for that entity. Click ‘More Actions’, and then ‘Export Chart’. NOTE: To re-import the chart use the ‘Import Chart’ option above.

When you export the chart, an xml file will be downloaded. Open this file (in notepad is fine). Within the <presentationdescription> tag, you will see a <series> tag containing another <series> tag for each of your series defined in the chart. On the second series, you will see an attribute called ‘YAxisType’. Remove this attribute so that it looks like the <series> tag above it.

    <Chart Palette="None" PaletteCustomColors="55,118,193; 197,56,52; 149,189,66; 117,82,160; 49,171,204; 255,136,35; 97,142,206; 209,98,96; 168,203,104; 142,116,178; 93,186,215; 255,155,83">
        <Series ChartType="Column" IsValueShownAsLabel="True" Font="{0}, 9.5px" LabelForeColor="59, 59, 59" CustomProperties="PointWidth=0.75, MaxPixelPointWidth=40">
        <Series ChartType="Column" IsValueShownAsLabel="True" Font="{0}, 9.5px" LabelForeColor="59, 59, 59" CustomProperties="PointWidth=0.75, MaxPixelPointWidth=40" YAxisType="Secondary">

Save the XML file, and then import the file using the same method you used to export it. Browse to the XML file, and then click next. You will be prompted to Replace the existing chart, or to Keep Both. Choose ‘Replace’.

The chart will be updated, and you can now check the chart again to view the changes (make sure to publish system charts). You will notice the chart now uses only one axis, and the values are compared accurately.

The drilldown functionality will still be available, so users can click on any of the bars to view the records that make up that section. You can also still modify the chart using the CRM chart designer without effecting the modified XML.

this blog post I will be discussing a few ‘best practices’ when using Dynamics CRM 2011 Workflow Processes, and in particular when using the ‘Wait Condition’. I will assume that you’re familiar with the basics of how to use workflow wait conditions, and so I will be focusing purely on a few of the tricks that I’ve picked up over the years while using workflows, so that you can use them in the most effective manner possible.


While a timeout is technically a wait condition, it appears differently once saved. Unlike a standard wait condition, a timeouts wait condition cannot later be modified, unless it is to simply change the date it is waiting until (as in, it must remain a ‘timeout’).

A timeout also cannot have multiple conditions defined within the same timeout; for example waiting until a date is reached and the status is complete (meaning the condition won’t be met until both of these are true).

So when should you use a Timeout and when should you use a Wait?

A ‘Timeout’ should be used when waiting until a date. For example, if you need to wait until 1 day before the due date of an appointment to send a reminder email, you need to use a Timeout. Timeouts can also be used to wait a static number of days. For example waiting 7 days duration before performing some other logic.

A standard ‘Wait’ can be used to wait for any other conditions. For example, if you have an opportunity pipeline workflow which creates an activity, you can use a wait condition to wait until the activity is completed before continuing onto the next phase.

Avoid using Process Execution Time in wait conditions, as these conditions will never be met and the workflow will continue waiting forever. Instead, you should always timeout until a specific date using the form assistant or a static date.


Wait conditions with no steps defined inside the actual wait condition will still wait until the condition is met before processing any steps after the wait condition.

By using this approach, it means there aren’t as many nested conditions, which makes it a lot easier to make changes to the workflow later on. When you delete a wait condition, it also deletes any steps defined within the wait condition, which means you would have to recreate any of the steps defined within the wait condition. It also means you can add your steps in first, and then add in the wait condition later.

If you have a parallel wait condition, where one of the two branches end the workflow, you can add the steps to end the workflow inside the wait, and then the steps for the other wait can be added outside (after) the whole wait condition. This will never be hit when the other wait condition is met, as the workflow will have been ended.


If you’re using a Timeout to wait until a date, and that date changes, the timeout will automatically adjust and wait until the new date. Even if that date is changed to be in the past, the timeout will readjust to the new date, and will fire instantly.

If the server goes down, or the async service stops, any workflows that are ‘waiting’ will be resumed when the server/async service comes back up. If the server/async is down at the exact time as when a wait condition is waiting until, the workflow will continue again when the server/async comes back up, and it will process the wait conditions that were due during the down time.


A Workflow triggered on Create will only ever run once for each record, whereas a workflow triggered by other means (such as field change) will fire a new instance of the workflow each time. If you are performing wait conditions, or sending emails for example, you don’t want these being sent twice for the same record.

If a date (such as an end date) won’t be entered right away, and you only want to start waiting when this date is entered, you can still trigger the workflow on create, and just timeout until this date. Even if there is no value, the workflow will wait until there is a value, and until that value is reached. If the workflow was triggered on change of the end date, you could potentially have multiple instances of the workflow running if the date were to change after it was initially set.

There are a few issues with this approach however. The workflows could potentially be waiting a long time before the date is set and reached, or the date could never be set at all, in which case the workflow would continue to wait forever. There are 2 ways to avoid these issues:

• Add a parallel wait branch to the wait condition, so you can wait a static length (such as 3 months after the created on). If the end date is not set and reached by that time the workflow will end, and optionally send someone an email or perform some other action.

• Trigger the workflow on change of the end date, but create a new hidden date field on the entity to prevent multiple instances of the workflow running at once.

In the workflow, before the wait condition, set the hidden date field to equal the end date. Add a parallel wait condition to wait until the end date does not equal the hidden date field. If this condition is met, end the workflow (as another instance of the workflow will now be running). This will ensure only 1 instance of the workflow is running per record.


If historic records are being created/updated, you may not want your workflow to continue processing. This would require a simple check condition before the wait condition to check Process Execution time is BEFORE the date you are waiting for. If the date is not in the future, the workflow would not continue.

This would mean that if your workflow was running on change of the date field, and it was changed to a date/time before today, the new instance of the workflow would be ended as the date is not in the future. Assuming you had ended any earlier workflows, this would mean the steps defined after the wait condition would not fire for that record.

This check would be completely optional and dependant of your particular requirements, as you may need the workflow to fire even on records where the date is set in the past.

NOTE: Without the check condition, a Timeout waiting until the End Time will be met straight away, even though the date has passed.



If you’re waiting until a date, make sure the date field contains data. If the field does not contain data, the workflow will error. This includes where the field initially has no value, and also where the field had a value, but was cleared before the wait condition was met.

To get around this, you can simply make the date field required, so that you know there will always be a value. Otherwise, you could add an extra check/wait condition into your workflow to make sure there is a value, or to wait until there is a value before waiting until the date.

You can also put logic in place to prevent the field value being cleared once it is set initially, so that the workflow won’t error while waiting for the date, but you can still add initial validation if the date won’t be entered right away.

In Dynamics CRM 2011, when you create an Invoice using Existing Products as the line items, these line items use the price from the related Product. If the price on the product changes, the Invoices that include the product will automatically be updated to include the new price. Note that this behaviour only occurs if the pricing on the Invoice has not been ‘locked’ – which means the prices are fixed (or confirmed), and so any changes to the product catalog will not modify this invoice.

This functionality of updating invoice products also applies to both Quotes and Orders, in that the line items using existing products will be automatically updated if the price list items change. Like invoice, these also have methods of ‘locking’ the pricing, which differs slightly for each.


While a Quote is in a draft state (as in, has not been ‘activated’), changes to a products price will automatically update the line items. Once the Quote has become ‘active’, changes to the product prices will no longer effect the quote line items.

If the Quote is ‘revised’, the status changes from Active back to Draft, and the quote line items will be updated to the latest product prices. Any product price changes will affect the line items again while the quote is draft.


An Order that is created from a Quote will automatically be ‘locked’, however one that is created manually from scratch will start out unlocked. As with the quote, any product price changes while the order is not locked will automatically update the line items.

To lock the pricing on an Order, click the ‘Lock Pricing’ button on the ribbon. Once the pricing has been locked, it can be unlocked again by clicking the ‘Use Current Pricing’ button. Similar to the Quote, when you use current pricing on an Order, the prices for all related line items will be updated to the current product pricing.

In the Totals section of the Order, you will see a check box called ‘Prices Locked’, which indicates whether the Order pricing is currently locked or not.


When an Invoice is created from an Order, the ‘Prices Locked’ setting will NOT be mapped across. If the Order pricing was locking, the new Invoice pricing will not be locked by default.

The pricing can be toggled using the ribbon (just like the Order), there is a button to ‘Lock Pricing’ when the invoice is not locked, and a ‘Use Current Pricing’ button when the invoice pricing is locked. Like the Order, this will update all line items to the new prices.

Once an Invoice has been completed or paid, the prices will no longer be affected by product price changes.

While this feature can be quite useful if your product prices are constantly changing, it can be potentially dangerous as it can mess up your data if you forget to lock pricing on your existing quotes/orders/invoices. If you are ever modifying product prices, just be aware of this, and how it may affect your existing records.

If you need to check what rollup your CRM is on, the easiest way to do this is to open your CRM server and check ‘Programs and Features’, then ‘View Installed Updates’ from the left hand side. This will display the installed rollups for existing CRM components.

Of course, if you’re not using CRM on-premise, you won’t have access to the server. Luckily, there are other ways to find your version number using outlook or the web client.

To find the version number from outlook (2010):

  1. Click the file menu in outlook
  2. Select CRM from the menu
  3. Click About Microsoft Dynamics CRM

To find the version number from the web client:

  1. Click the file menu in the web client
  2. Select Help from the menu
  3. Click About Microsoft Dynamics CRM

The following window will appear, showing the build number for the CRM 2011 Server, and the CRM 2011 Outlook Client (if installed).

The following table outlines the rollup that matches each version number, including the release dates for each rollup, prerequisites, and a link to the KB article for more information:

Update Version Date Published KB Article Prerequisite
RC 5.0.9688.53 14 Dec 2010
RTM 5.0.9688.583 16 Feb 2011 KB2461082
Rollup 1 5.0.9688.1045 4 Apr 2011 KB2466084 RTM
Rollup 2 05.00.9688.1155 6 Jun 2011 KB2466086 RTM
Rollup 3 05.00.9688.1244 26 Jul 2011 KB2547347 RTM
Rollup 4 05.00.9688.1450 19 Sep 2011 KB2556167 RTM
Rollup 5 05.00.9688.1533 20 Oct 2011 KB2567454 RTM
Rollup 6 05.00.9689.1985
12 Jan 2012
20 Jan 2012
KB2600640 RTM
Rollup 7 05.00.9690.2165 23 Mar 2012 KB2600643 Rollup 6
Rollup 8 05.00.9690.2243 3 May 2012 KB2600644 Rollup 6
Rollup 9 Cancelled Rollup 6
Rollup 10 05.00.9690.2720 16 Aug 2012 KB2710577 Rollup 6
Rollup 10 v2 05.00.9690.2740 4 Oct 2012 KB2710577 Rollup 6
Rollup 11 05.00.9690.2835 11 Oct 2012 KB2739504 Rollup 6
Rollup 11 v2 05.00.9690.2838 (Client)
05.00.9690.2839 (Server)
15 Oct 2012 (Client)
22 Oct 2012 (Server)
KB2739504 Rollup 6


According to this table, the system in my screenshot above is on Rollup 11 v2 for both the Server and Outlook Client.

We built a custom Silverlight screen for one of our customers, which automatically opens when a record is opened. For some users however, the Silverlight screen would not open. The form loads fine, but the Silverlight just wouldn’t pop up. We tried reproducing this on our own computers, but could not achieve the same result. Even after checking the IE Pop-up Blocker, we could not produce the same issue.

After some investigation, we discovered that the Google Toolbar in IE has a pop-up blocker of its own that is preventing the Silverlight screen from opening. As you can see in the screenshot above, it mentions at the top that there was a Pop-up blocked by Google Toolbar, however this message is not displayed for long, and so it can be difficult to notice. There is another message at the bottom of the page: “Pop-ups were blocked on this page. Press the “Ctrl key when clicking to allow pop-ups.” – however doing this doesn’t actually seem to help.

Once we confirmed it was the Google toolbar, it was fairly simple to disable the pop-up blocker.

  1. Open IE.
  2. On the Google Toolbar, click ‘More’.
  3. Select Pop-up Blocker, and then click Pop-up Blocker again from the menu.

  1. Note: If Pop-up Blocker is not available under the ‘More’ menu, it is probably already being displayed on the toolbar.
  2. The pop-up blocker icon should appear on the toolbar, and should look like the icon below.

  1. Note: If the icon looks like this:  (meaning pop-ups are being blocked), click the icon to allow pop-ups.

When we open our record now, the Silverlight screen pops up correctly.

If there are still problems we can disable the Google toolbar completely by clicking the ‘X’ on the left side of the Google toolbar.

If you ever have the same problem where CRM screens are not opening for some users, check their add-ins/toolbars for IE, as there are other toolbars (such as yahoo) which have built in pop-up blockers as well.

Microsoft Dynamics CRM has encountered an error. Please tell Microsoft about this problem. Send Error Report, or Don’t Send.

If you receive a lot of errors like this while using Dynamics CRM 2011, you may already know that you can change your personal options to automatically send these error reports to Microsoft, or to never send this. This will mean those errors will not pop up on your screen anymore as they will automatically be handled. Most of the time however, we have several users who are all going to experience this same issue, and so we don’t want to have to go through each users login to change their personal options! Fortunately, there is a way to globally define this setting. This means you can decide to send or not send errors to Microsoft for all users, so that this type of error message doesn’t bother another user ever again!

To define this global setting, navigate to Settings, Administration, and then click on Privacy Preferences.

A dialog box will appear to specify your organizations privacy settings. Click on the ‘Error Reporting’ tab, and then select to specify the error notification preferences for all users. You can then choose whether to automatically send or not send error reports. The recommended setting here is to automatically send errors, so that Microsoft can fix these in future rollups.

Once you click ok, the changes will be applied. If you (or any other users) try and set their personal options now, the ‘Privacy’ tab will be removed, as it is now managed at the organization level. If any of those errors ever occur again in the future for any users, they will not be annoyed by a pop up message.