title: Why is infinite loop protection being triggered on my CRM workflow?
body: <h1>Update</h1>
  
  <p>I should have added from the outset - this is in Microsoft Dynamics CRM <strong>2011</strong></p>
  
  <hr>
  
  <p>I know CRM well, but I'm at a loss to explain behaviour on my current deployment.</p>
  
  <p>Please read the outline of my scenario to help me understand which of my presumptions / understandings is wrong (and therefore what is causing this error). It's not consistent with my expectations.</p>
  
  <h1>Basic Scenario</h1>
  
  <p><ul>
  <li>Requirement demands that a web service is called every X minutes (it adds <em>pending</em> items to a database index)</li>
  <li>I've opted to use a workflow / custom entity trigger model (i.e. I have a custom entity which has a CREATE plugin registered. The plugin executes my logic. An accompanying workflow is started when <strong>"completed" time + [timeout period]</strong> expires. On expiry, it creates a new trigger record and the workflow ends). </li>
  <li>The plugin logic works just fine. The workflow concept works fine to a point, but after a period of time the workflow stalls with a failure:</p>
  
  <blockquote>
    <p>This workflow job was canceled because the workflow that started it included an infinite loop. Correct the workflow logic and try again. For information about workflow logic, see Help.</li>
    </ul>
    So in a nutshell - standard infinite loop detection. I understand the concept and why it exists.</p>
  </blockquote>
  
  <h1>Specific deployment</h1>
  
  <p>Firstly, I think it's quite safe for us to ignore the content of the plugin code in this scenario. It works fine, it's atomic and hardly touches CRM (to be clear, it is a pre-event plugin which runs the remote web service, awaits a response and then sets the "completed on" date/time attribute on my Trigger record before passing the Target entity back into the pipeline) . So long as a Trigger record is created, this code runs and does what it should. </p>
  
  <p>Having discounted the content of the plugin, there might be an issue that I don't appreciate in having the plugin registered on the pre-create step of the entity...</p>
  
  <p>So that leaves the workflow itself. It's a simple one. It runs thusly:</p>
  
  <ol>
  <li>On creation of a new Trigger entity...</li>
  <li>it has a Timeout of Trigger.new_completedon + 15 minutes</li>
  <li>on timeout, it creates a new Trigger record (with no "completed on" value - this is set by the plugin remember)</li>
  <li>That's all - no explicit "end workflow" (though I've just added one now and will set it testing...)</li>
  </ol>
  
  <p>With this set-up, I manually create a new Trigger record and the process spins nicely into action. Roll forwards 1h 58 mins (based on the last cycle I ran - remembering that my plugin code may take a minute to finish running), after 7 successful execution cycles (i.e. new workflow jobs being created and completed), the 8th one fails with the aforementioned error.</p>
  
  <h1>What I already know (correct me where I'm wrong)</h1>
  
  <p><a href="http://msdn.microsoft.com/en-us/library/microsoft.xrm.sdk.iexecutioncontext.depth.aspx" rel="nofollow">Recursion depth, by default, is set to 8</a>. If a workflow / plugin calls itself 8 times then an infinite loop is detected.</p>
  
  <p><a href="http://msdn.microsoft.com/en-us/library/microsoft.xrm.sdk.iexecutioncontext.depth.aspx" rel="nofollow">Recursion depth is reset every one hour</a> (<a href="http://gonzaloruizcrm.blogspot.co.uk/2011/05/quite-often-we-have-business-process.html" rel="nofollow">or 10 minutes - see "Warnings" in linked blog</a>?)</p>
  
  <p><a href="http://blog.dorrekens.com/index.php/list/137-mscrm-infinite-loop-for-plugins" rel="nofollow">Recursion depth settings can be set via PowerShell</a> or SDK code using the <a href="http://msdn.microsoft.com/en-us/library/gg328063.aspx" rel="nofollow">Deployment Web Service</a>  <em>in an on-premise deployment only</em> (<a href="http://msdn.microsoft.com/en-us/library/gg328563.aspx" rel="nofollow">via the Set-CrmSetting Cmdlet</a>)</p>
  
  <h1>What I don't want to hear (please)</h1>
  
  <p><strong>"Change recursion depth settings"</strong></p>
  
  <p>I cannot change the Deployment recursion depth settings as this is not an option in an online scenario - ultimately I will be deploying to CRM Online too.</p>
  
  <p>"<strong>Increase the timeout period on your workflow</strong>"</p>
  
  <p>This is not an option either - the reindex needs to occur every 15 minutes, ideally sooner. </p>
  
  <h1>Update</h1>
  
  <p>@Boone suggested below that the recursion depth timeout is reset after 60 minutes of <strong>inactivity</strong> rather than every 60 minutes. Therein lies the first misunderstanding.</p>
  
  <p>While discussing with @alex, I suggested that there may be some persistence of CorrelationId between creating an entity via the workflow and the workflow that ultimates gets spawned... Well there is. The CorrelationId is the same in both the plugin and the workflow and any records that spool from that thread. I am now looking at ways to decouple the CorrelationId (or perhaps the creation of records) from the entity and the workflow.</p>