Processes (Workflows) Best Practices

When enabling new workflow options in Microsoft Dynamics CRM 2011, the overall performance of the implementation can be affected. Keep in mind the following best practices, when considering how to ensure that Microsoft Dynamics CRM workflow functionality performs optimally for a particular implementation.

  • Determine the business purposes for implementing workflow prior to enabling the functionality. During planning, analyze the business scenario and define the goals of workflow within the solution. Workflow functionality can provide for businesses’ process automation, exception handling, and end-user alerts.

Decide on the appropriate security/permissions model for workflow. With established business goals in place, determine the scope of users that will be affected by the workflow implementation. Users should be identified to determine who will create and maintain workflows, apply and track workflows, and troubleshoot workflow issues.

  • Use the Scope property sensibly. The Scope property associated with workflow rules defines the extent of records affected by that rule. For example, rules configured with a User scope affect only the records owned by that user, while rules configured with an Organization scope will affect all records within organization, regardless of which user owns each record. When creating workflows make sure to identify the appropriate scope value for each workflow rule to minimize the number of related system events.
  • Take into consideration the overall load associated with workflow within a deployment. Think about the number of instances that each workflow definition triggers. Then also consider these factors which affect load of workflows:
    • number of workflows
    • which entities
    • number of records
    • data size
    • data load

Considering the factors above in the system on a typical day provides for better comprehension of the processes and load variance. Based on this analysis, the workflows can be optimized as required.

  • Review workflow logic wisely. Consider the following factors:
    • Workflows that include infinite loopbacks, due to semantic or logic errors never terminate through normal means, therefore greatly affect overall workflow performance.
    • When implementing workflow functionality within a CRM 2011 deployment, be sure to review the logic in workflow rules and any associated plug-ins for potential loopback issues.
    • As part of ongoing maintenance efforts, periodically publish workflow rules and review them to ensure that duplicated workflow rules are not affecting the same records.
  • When defining workflows that are triggered on update events, be cautious. Taking into account the frequency at which ‘Update’ events occur, be very particular in specifying which attributes the system looks for to trigger updates. Also, avoid using ’Wait’ states in workflows that are triggered on Update events.
  • Scale out as necessary, to improve performance in large deployments. Use dedicated computers to run the Async service for large-scale deployments. That being said, increasing the number of servers running the Async service creates additional stress on the server running Microsoft SQL Server. Therefore, make sure to follow appropriate optimization and tuning strategies on the data tier and investigate the possibility of increasing the number of computers running Microsoft SQL server.
  • Test workflows. Make sure to test and monitor the performance of new workflow functionality before implementing it in a production environment.
  • Async plug-ins. Think through whether plug-ins should run synchronously or asynchronously. When the priority is user responsiveness, running a plug-in asynchronously will enable the user interface to respond quicker to the user. But, asynchronous plug-ins introduce added load to the server to persist the asynchronous operation to the database and process by the Async Service. When scalability is essential, running plug-ins synchronously typically requires fewer loads on the servers than running plug-ins asynchronously.
  • Balancing workflows and asynchronous plug-ins. Asynchronous plug-in and workflow records in the asyncoperationbase table are managed with the same priority. Hence, introducing a large number of asynchronous plug-ins into a system can reduce overall throughput or increase the time between triggering and processing of individual workflows. For that reason, make sure to consider the relative importance of the workflows in the system before adding numerous asynchronous plug-ins to the solution.
  • Child Workflows. Child workflows run as independent workflow instances from their parents. This can facilitate parallel processing on a system with spare capacity, which can be useful for workflows with multiple independent threads of high processing activity. Additional overhead can be introduced if the parallel processing is not critical because other workflow logic threads are blocked waiting for external events to occur.

NOTE: If workflow functionality within a CRM 2011 implementation is not acting as expected, verify that the Async service is running properly. Often, restarting the Async service will unblock workflow processing without affecting the functionality of the workflows that were in the pipeline.

  • Monitor the Microsoft Dynamics CRM 2011 database for excess workflow log records. Workflow processing in Microsoft Dynamics CRM depends on on the Asynchronous Service, which logs its activity in both the AsyncOperationBase table and WorkflowLogBase tables. Performance may be affected as the number of workflow records in the CRM 2011 database grows over time.

Microsoft Dynamics CRM 2011 includes two specific settings, ‘AsyncRemoveCompletedJobs’ and ‘AsyncRemoveCompletedWorkflows’, which can be configured to ensure that Asynchronous Service automatically removes log entries from the AsyncOperationBase and WorkflowLogBase tables. These settings are as follows:

    • The ‘AsyncRemoveCompletedWorkflows’ setting is visible to users in the interface for defining new workflows, and users can set the Removal flag independently on each of the workflows they define.NOTE: When registering an Async plug-in, users can also specify that successfully completed Async Plugin execution records be deleted from the system.
    • Using the deployment Web service, users can change the AsyncRemoveCompletedJobs setting by. Nonetheless, the setting is by default configured to True, which ensures automatic removal of entries for successfully completed jobs from the AsyncOperationBase table.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s