When using an AddRelationship or RemoveRelationship trigger to fire of workflows in Service Manager you might end up with an unwanted scenario of competing workflows.

Let’s say that you implement a rule that subscribes to relationships being added between a work item and configuration items (such as “configuration items to change” in a change request). The normal behavior after implementing this would be that multiple workflows where fired if multiple configuration items where related to the change request at the same time.

The behavior above is good if you want to do something specific with each configuration item being added to a change request. In certain scenarios though you might only be interested in firing of one workflow when relationships are added (or removed), no matter the amount of relationship changes being committed to the Service Manager database. If this is the case, you could end up with multiple workflows competing to finish of the same task.

Say you want to do something to a change request as soon as a (any) configuration item is added to the change request through the “configuration items to change” relationship. In this case, you only need one workflow to fire of, no matter how many configuration items were added in the transaction (commit). In scenarios like these the “top secret” BatchSize value of subscriptions comes into play. After some digging around I found that the value of BatchSize parameter actually limits the amount of write actions being executed based on a subscription (per poll). This effectively means that setting the BatchSize value to 1 will make sure that only one workflow (write action) is executed even though the condition of the subscription rule was fulfilled by multiple objects.

The MP xml below comes from a management pack where I’ve changed the BatchSize to 1 to fire of a single workflow when a configuration item(s) is added to a change request. The workflow in this specific case was used to add a special activity to all change requests which has one or more “configuration items to change”. The workflow would start with checking of the special activity had already been added, if not it would add the activity. This way, if a previous workflow has already added the activity, the following workflows (triggered by new configuration items being added) would abort at a very early stage, perfect! But if the BatchSize hadn’t been tuned to 1, adding multiple configuration items to the change (where no “configuration items to change” had previously been added) at the same time, would cause multiple workflows to fire of. All of them would think that they were first and they would end up competing for adding the special activity.

<DataSource ID="DS" TypeID="SystemCenter!Microsoft.SystemCenter.CmdbInstanceSubscription.DataSourceModule">
 <Subscription>
  <RelationshipSubscription RelType="$MPElement[Name='WorkItem!System.WorkItemAboutConfigItem']$" SourceType="$MPElement[Name='WorkItem!System.WorkItem']$" TargetType="$MPElement[Name='System!System.ConfigItem']$">
   <AddRelationship />
  </RelationshipSubscription>
  <PollingIntervalInSeconds>30</PollingIntervalInSeconds>
  <BatchSize>1</BatchSize>
 </Subscription>
</DataSource>