locked
Are callouts supposed to be triggered by workflow rules? RRS feed

  • Question

  • We are running CRM 3.0.  We've got a PostSetState callout on the opportunity entity.  We've also got a workflow rule that changes the state of an opportunity to "Lost - Canceled".  The callout fires when the user manually closes an opportunity but when the user applies the workflow rule to a selection of opportunities the callout does not execute.  Is this expected?  If so, what's the best way to implement this in a workflow rule?

     

    The callout in question is designed to find all of the open phone calls for an opportunity that has been closed and it sets them to the canceled state/status.  The callout runs fine on its own.  It is subscribed to the postsetstate event and it uses a retrievemultiplerequest to fetch all of the open, related phone calls and then it iterates through the collection executing a setphonecallstaterequest to update the status to canceled for each of them.

     

    The workflow rule simply sets the opportunity state to lost and the status reason to canceled.

     

    Your help will be appreciated.

    Friday, June 13, 2008 10:31 PM

Answers

  • You know what?  Never mind.  I restarted the server and now the workflow is triggering the callout.  I must be that somehow I've not restarted the workflow service (or the server) in the months since I rolled out that callout.  The workflow rule was new. 

     

    Monday, June 16, 2008 3:11 PM

All replies

  • This may help clarify:
    http://mscrm-developer.blogspot.com/2007/07/callout-vs-workflow.html

    Callouts are not triggered by workflows.  A callout can be connected to a workflow.  This is referred to as a workflow assembly:
    http://blogs.inetium.com/blogs/vbullinger/archive/2006/10/23/417.aspx
    Saturday, June 14, 2008 11:29 AM
    Moderator
  •  

    I dont think so

     

    Following guidelines can help you decide when to use a callout versus a workflow assembly:

    Use callouts

    •  To alter data prior to submission to the platform.
    •  To take action after an update to an entity. (Workflow does not provide an easy trigger mechanism for the update event.).
    • When you need a synchronous transaction and an immediate response.
    • To take action before or after the merging of two records or the deletion of a record.
    • When accessing custom entities that are organization-owned. Workflow can be used only on entities that have user ownership.

    Use workflow

    • For all asynchronous actions—transactions that can be completed without having the user wait for their completion. A typical asynchronous action might be to send an e-mail message after some condition is met. The user usually wouldn’t have to wait until the system created and sent the message.
    • For simple common tasks. The Workflow Manager has a list of actions, already built and available for use, that requires no custom application development. Available actions include creating new records (such as Activities or Notes), sending e-mail messages, and updating values on related entities.
    • To allow more configuration options to the user who is creating the workflow logic. Because the user builds the workflow rule with the rule editor, he or she can also alter it without necessarily requiring programmatic interaction.
    • When you need a user to manually execute the necessary logic.
    •  
    Monday, June 16, 2008 10:12 AM
    Moderator
  • I can certainly understand and appreciate the difference between workflow rules and callouts.  What I don't understand is why an extension to the business logic (callouts) is being ignored by the workflow engine which one might think should be a primary consumer of the business logic. 

     

    So this separation now means I have to rework the code I've written to have a generic method that will process the phone call cancelations that is called by two separate platform extensions - the callout and a workflow rule.  And I have to remember to add that workflow assembly to any future workflow rule that performs a similar operation.  Does this sound right?

     

    Just curious, would any of this be different in 4.0?

    Monday, June 16, 2008 2:58 PM
  • You know what?  Never mind.  I restarted the server and now the workflow is triggering the callout.  I must be that somehow I've not restarted the workflow service (or the server) in the months since I rolled out that callout.  The workflow rule was new. 

     

    Monday, June 16, 2008 3:11 PM
  • An IISRESET may have done so as well

     

    Tuesday, June 17, 2008 3:43 AM
    Moderator
  • Or restarting the Workflow service.

    Tuesday, June 17, 2008 3:44 AM
    Moderator