Demystifying the Recurring Appointment series expansion in Microsoft Dynamics CRM 2011

Microsoft Dynamics CRM 2011 Beta is out and so is the support for creating and managing recurring appointments within Microsoft CRM.

Now we can create and manage recurring appointment within Microsoft Dynamics CRM 2011 using its familiar Web client user interface and it also allows you to perform full bi-directional synchronization with Microsoft Dynamics CRM Client 2011 for Outlook.

Recurring appointments look and feel is almost similar to Outlook’s Recurring appointments, this was done to ensure that users get familiar interface of Outlook’s recurring appointment but there are two important differentiators as well that I want to highlight here.

1. Outlook Recurring Appointments follow Rule based OnDemand expansion model while in CRM occurrences get created and persisted in Database as individual Appointment records. This expansion based model allows other components of CRM to work independently on individual appointments records.

2. Unlike Outlook, CRM allows us to update recurrence rule of recurring series and still maintain past history of recurring series. On every update of recurrence information, past appointment instances of recurring series are preserved and they can be viewed from a common grouping link in recurring series records.

In this blog post I wanted to share more detail on recurring appointment series expansion logic, as it has some settings that you can configure as per your organization’s business requirements.

Expansion based model works best for business system like CRM very well but it has its own set of challenges, like high storage cost and initial processing cost in series expansion. Series maintenance cost(like update and delete cost) is also high when series definition changes. To address some of these concerns partial expansion based model is followed in CRM, which mitigates performance issues as well as allows an organization to define its own expansion rule as per business needs for long running recurring appointments.

This is how we define partial expansion model –

I. Initial expansion window configurable by business policy.

II. Future expansions done by background expansion service for a configurable time window on incremental basis.

Now let’s take one concrete example to explain how partial expansion based approach works. Assume you have a never ending recurring series definition; in this case partial expansion of a recurring series will work in this way.

I. On recurring appointment series creation, immediately 15 appointment instances would be created (controlled by RecurrenceExpansionSynchCreateMax setting).

II. An Asynchronous “OnDemand” expansion job would be created, which will expand the series for next 12 months time window (controlled by FutureExpansionWindow).

III. There is a weekly “Recurring” series expansion job pre configured into CRM system which will take care of expanding any series for next 7 days into system. This job will keep expanding series regularly and it will ensure that you have access to next 12 month’s worth of instances for any series.

There are a number of organization settings that you can tweak to adjust recurring series expansions as per your organizations need.

a. RecurrenceExpansionSynchCreateMax – Specifies the maximum number of instances to be created synchronously after creating a recurring appointment. CRM default is 15 instances. This setting allows us to control synchronous creation of series instances. Default value 15 allows us to work immediately on created series instances, having a larger value will keep user waiting for series creation operation to complete.

b. FutureExpansionWindow – Specifies the maximum number of months in future for which the recurring activities can be expanded. CRM default is 12 months. After this period series instances will keep on expanding on Weekly basis (like a sliding time window) until series expansion is fully complete as per series end date definition. This setting ensures that at any day you will be able to see instances in CRM calendar for future time window controlled by FutureExpansionWindow.

c. PastExpansionWindow – Specifies the maximum number of months in past for which the recurring activities can be created. CRM default is 3 months. On web client this setting prevents user to specify recurring series start date more than three months in past. Further, this setting allows us to control how many past instances of series we want to synchronize from Outlook side. Generally, most of the time we are interested in present information instead of past information so it will prevent the synchronization of very large number of past instances from Outlook side.

d. RecurrenceExpansionJobBatchSize – Specifies the value for number of instances created in on demand job in one shot. There is no CRM default value for this setting, which means this setting is ignored unless set to some positive integer value. This performance tuning setting allows to tune Asynchronous expansion of recurring series, if there are too many instances that needs to be created because “FutureExpansionWindow” is very large, in such cases this setting will allow automatic pausing of recurring series expansion job to give other Asynchronous jobs an opportunity to complete their work.

e. RecurrenceExpansionJobBatchInterval – Specifies the interval (in seconds) for pausing expansion job. CRM default is zero seconds. If pausing happens because of “RecurrenceExpansionJobBatchSize” setting, then paused series expansion job will sleep for the specific seconds as per this setting. This setting should not be changed unless you want to do expansion related performance tuning yourself.

These settings are not available in System Settings page in CRM, so you’ll want to write a simple SDK program to change them if you want to tap into them.

You can find more detail in SDK documentation on how to work with recurring appointments and it’s interaction with other sub systems in CRM.


Prabhat Pandey

Comments (2)

  1. Sanjay Munjal says:

    Thanks for your blog post. I find is very useful.

    However, why other activity type (Task, Phone Call etc) are not supported for recurring functions? I am sure it is easy to do and incorporate before beta finishes. We have seen our customer asking for this. For e.g., having a service appointment or a follow up phone call with customer which happen on regular basis. It would be great to get this included in the final product.


  2. Prabhat Pandey says:

    @Sanjay: Thanks for your feedback. Recurring ServiceAppointment behavior is similar to Recurring Appointment but Recurring Task or Recurring Phonecall have different expansion mechanism. We wanted to support them in this release but they could not bubble up due to other priorities.