In this and the following two posts, I would like to suggest a solution to a common business problem of executing business logic operation in a scheduled reoccurring manner.
While the current post describes the business problem and a solution concept, the next posts will suggest an actual implementation, based on the Asynchronous Batch Process Pattern described here.

Business Problem

I am often asked by customers about implementing business logic operations in a scheduled reoccurring manner. Here are some of the business requirements I have encountered:

These requirements have some common characteristics: scheduled, repeating, asynchronous activation of a business logic for a selected collection of business records.

Common Solutions

There are some standard solutions in Microsoft Dynamics CRM for such business requirements and the common two are described in the following table:

# Solution Disadvantages
1. Custom .NET code executing a query to retrieve target business records and implementing business logic.
Scheduled and activated by Windows Service or Windows Task Scheduler
  • Can not be contained in MSCRM 2011 Solution
  • For Online/IFD deployments, requires Azure/On premise hosting environments for .net code and scheduling components 
  • Business logic change usually require code compilation cycle
2. Recursive Workflow rule activated for each target business record.
Business logic executed by native Workflow Step or Custom Activity .NET code
  • Custom Activities are not supported in Online deployments
  • Workflow Steps are limited to specific set of actions and can not perform actions such as Share record
  • Recursive Workflow rules are hard to manage and diagnose


The main disadvantage in both common solutions, is the lack of support in Online deployments. This usually means that part of the solution is implemented in a different hosting environment such as Azure of On premise.

The Asynchronous Batch Process Pattern

The Asynchronous Batch Process Pattern is based on three basic elements:

  1. Schedule: managed by a Scheduling component, able to invoke an Action in a predefined date and time
  2. Action: a business logic operation performed of a collection of business records by the Executing component
  3. Target business records: A collection of business records defined by a Query Definition


The Action is applied to the target business records on a specified schedule

Asynchronous Batch Process Pattern diagram


While this looks like a simplistic and trivial concept, the pattern defines the weakest coupling possible between the three components. The Scheduling Component is oblivious to the Action it invokes, and the Action delegate is unaware to Target Business Records population it acts upon.

This pattern allows a robust yet flexible solutions to the aforementioned business problem.


Suggested Implementation Features

In the following posts, I will describe a possible Implementation based on the Asynchronous Batch Process Pattern.
I will consider this Implementation preferred over the two solution mentioned above if it will support the following main features:

Add comment " class="ir icon-in">linkedin twitter email