locked
Use of Workflow-Execution Time, causing performance problems? RRS feed

  • Question

  • Hi,

    I'm currently investigating an issue where the performance of CRM is very slow and the CPU usage is 100%, we've done some analysis and we're pretty convinced that workflows are the problem. I think I've ruled out the Workflow Expansion Task issue as there doesn't seem to be many of them (in fact, the AsyncOperationBase table doesn't have an excessive number of rows in it). 

    Anyway, I found a blog article about CRM Workflow Best Practices (http://blogs.msdn.com/b/crm/archive/2010/01/15/microsoft-dynamics-crm-workflow-authoring-best-practices.aspx) and was particularly interested in the Workflow Execution Time section. I've emailed the author (Jim Glass) who suggested that I post my question here - so here it is :)

    The client has created a load of workflows and many of them are programmed to wait a certain number of days. After reading the article I went back to CRM and checked one of these workflows and lo-and-behold the first part of the workflow is: Timeout until Days: 22 after workflow-execution time then ...

    Am I right in assuming that this is a "bad thing(tm)" - and will mean that this workflow will run forever causing performance issues, as mentioned in the article.

    Forgive the simplicity of this message as I'm no expert when it comes to sorting out workflows (I passed one exam and I'm now considered the company expert :))

    Any help would be greatly appreciated,

    Cheers, Dan.


    Tuesday, July 26, 2011 3:48 PM

All replies

  • Indeed, the article hits the nail on the head. The correct use of Execution Time is to note the DateTime in which the step is executed. So if you want to wait, say until the end of a Stage in a process, then log the time that it occured into a DateTime field (eg, Proposal Completed On = ExecutionTime), then that is the way to go.

    As the article described, if you wish to wait x Number of days after the workflow step was kicked-off, use Timeout = Duration.

    Since you're the defacto workflow guy now, another thing to seriously consider applying to your clients litany of workflows is the use of calling child workflows from longer workflow processes as a mean to modularize lengthy complex workflows.

    Jim Describes it very well, but I want to give you a real world example that I came across recently:

    There was a long workflow that described an entire process from start to finish. Along the way, it sent a lot of email notifications (which, in an of themselves are a bad idea, but that's another story) to people each step of the way, using the same email text, with the same fields, only difference being that the values had changed in the course of the sales process. Once sent, it updated the Opportunity with the DateTime the email was sent, and moved the process to the next stage. So anytime we had to add text, or add a new dynamic value, we had to update 15 Send Email steps with the exact same text and values.

    This is the perfect opportunity to create a child workflow that simply sends an Email Template and then updates the DateTime (properly using ExecutionTime) on the Opportunity. Now, after each stage is complete, you can simply call this child workflow. If the Email Template need to be updated, you only need to do it in one place.


    --Dodd
    • Edited by MDodd73 Friday, July 29, 2011 8:43 PM Specified Timeout Condition
    Friday, July 29, 2011 8:38 PM