Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
Workflow Infinite Loop (I know Why) What to Do RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Good Morning,

    I have created a pretty basic workflow for updating an opportunity and it work as expected.....that is until you goto system jobs and see that it ran 8 times before Msoft shut it down as an infinite loop condition. I've gone through the workflow several times and the only possible cause is the Update Record trigger.

    I designed my workflow that when an opportunity is updated a field is checked then another updated based upon the value in the first field.....well it would seem this workflow then fires the update event and another workflow kicks off....and so the cycle repeats itself till Msoft kills it.

    I've looked and Googled but I am unable to find a flag or some method for "excluding" workflow updates from the update trigger.

    Any information would be greatly appreciated

    JB

    Wednesday, October 17, 2012 1:58 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    just an idea: you can add a new custom field to your opportunity, for example a boolean field named "Workflow executed" with default value to false. In your workflow update this value to true. Then add a Condition to your workflow to abort execution if this field's value is true.

    Greetings,

    Pavlos

    Please mark this reply as an answer and vote it as helpful if it helps you find a resolution to your problem.
    View my latest gallery contribution here.
    Visit my blog here.


    Wednesday, October 17, 2012 2:03 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    If you are working with custom workflow activities:

    Have a look at the IExecutionContext.Depth Property of the IExecutionContext Interface

    Used by the platform for infinite loop prevention. In most cases, this property can be ignored.

    Every time a running plug-in or Workflow issues a message request to the Web services that triggers another plug-in or Workflow to execute, the Depth property of the execution context is increased. If the depth property increments to its maximum value within the configured time limit, the platform considers this behavior an infinite loop and further plug-in or Workflow execution is aborted. The maximum depth (8) and time limit (one hour) are configurable by the Microsoft Dynamics CRM administrator.

    Jason Lattimer


    Wednesday, October 17, 2012 7:41 PM
    Moderator

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    just an idea: you can add a new custom field to your opportunity, for example a boolean field named "Workflow executed" with default value to false. In your workflow update this value to true. Then add a Condition to your workflow to abort execution if this field's value is true.

    Greetings,

    Pavlos

    Please mark this reply as an answer and vote it as helpful if it helps you find a resolution to your problem.
    View my latest gallery contribution here.
    Visit my blog here.


    Wednesday, October 17, 2012 2:03 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    That's a very good idea. So good you'd think Microsoft would have come up with it and shipped it OOB that way.
    Wednesday, October 17, 2012 2:06 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    If you are working with custom workflow activities:

    Have a look at the IExecutionContext.Depth Property of the IExecutionContext Interface

    Used by the platform for infinite loop prevention. In most cases, this property can be ignored.

    Every time a running plug-in or Workflow issues a message request to the Web services that triggers another plug-in or Workflow to execute, the Depth property of the execution context is increased. If the depth property increments to its maximum value within the configured time limit, the platform considers this behavior an infinite loop and further plug-in or Workflow execution is aborted. The maximum depth (8) and time limit (one hour) are configurable by the Microsoft Dynamics CRM administrator.

    Jason Lattimer


    Wednesday, October 17, 2012 7:41 PM
    Moderator
  • Question
    Sign in to vote
    1
    Sign in to vote

    There are times when you do legitimately want a recursive loop to happen and as long as you insert a wait condition of 1hr or greater, the loop detection won't kill the workflow. Pavlos and Jason's answers are correct.

    Rob

    Microsoft Certified Technology Specialist (CRM) GAP Consulting Ltd Microsoft Community Contributor Award 2011

    Wednesday, October 17, 2012 8:29 PM
    Answerer
  • Question
    Sign in to vote
    0
    Sign in to vote

    Well in this case it was a simple need so I didn't create a custom object implementing the Interface. However you did say that the maximum depth and time limit are set by the CRM Administrator. I went throught the Administration and System Setting to no avail. So I changed my Google terms slightly and came up with this post: http://social.microsoft.com/Forums/en/crm/thread/1b164a2f-d2a2-4a6a-813e-716c8771ee78 which is from a little over a year ago. While I have no qualms about running custom TSQL in my sandbox I do not consider it a viable solution for a production environment.

    So I'm back to Pavlos band-aid for now...

    Wednesday, October 17, 2012 8:38 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    For anyone else out there here is what I did. As Pavlos so brilliantly suggested I created a new boolean field in the opportunity entity called TerminateFlow and set it to false.

    Now when my workflow executes it checks to see if that value is false. If it is it continues with any other checks and / or procedures. At the end of said checks and / or procedures I set the TerminateFlow to true. Then when the workflow begins a second time it sees that terminateFlow is true and skips all the other stuff BUT before you terminate the workflow remember to set TerminateFlow back to false for the next time the record changes.

    FWIW

    JB

    Tuesday, October 23, 2012 4:02 PM