Details about this thread
  • State Not Answered
  • Replies 7 replies
  • Subscribers 315 subscribers
  • Views 2689 views
  • Users 0 members are here
Related content from around SugarClub

Workflow Help: Send an email when an opportunity's related task has been completed

Armena Ballard

Hello -

I'm trying to build a workflow in SugarBPM: when an opportunity record's sales stage field changes, a task is automatically created asking the user assigned to the record to update specific fields. Then, once the user marks the task as complete, an email is triggered to specific users (in this case our CRO, Talent Acquisition, and Operations) with the new field values so deal coaching can be provided. 

I believe that I have the process set up correctly except in one instance. The start event is set up with the Sales Stage field changing to Closed Won. That goes to the action, which creates a task related to the opportunity record.

After that, I have a "Receive Message" event, where the criteria offered includes either all related records or any related record:

In my mind, neither of these options work as I want the email notification being sent after this step to be predicated on the task created earlier in the workflow being marked as complete. My concern is if there are multiple tasks related to this one opportunity record, this email notification to Paul Stab would be triggered unnecessarily.

Is there a way to accomplish what I'm trying to do? If so, what's the best way to set up the workflow? Thank you!

Parents
  • 0

    On the basis that when BPM creates the Task you can populate the Task Fields, you can populate a Task Field with specific criteria (even use a standard unique Description for these tasks) and then use that as the criteria in the Task Module field Evaluation to trigger the next step.

  • 0 in reply to Greg Barrass

    Great. I do have a standard pre-defined description for these tasks, so that's perfect.

    So I'd update the criteria on Message Event #1 to be Sales Stage is "Closed Won" AND Description is ".....", correct?

    Thanks for your help, Greg!

  • 0 Sugar Employee Badge in reply to Armena Ballard

    Just to be clear, the Message Event #1 criteria also has Task Status = Completed, right?

    I just wanted to mention that if you use an editable field (such as Description is OOTB), it is always possible that your special description value won't match because someone else has updated it while you're waiting for the task to be completed. If that's a concern, it would be safer to make your criteria on a field that users can't edit, such as a role-restricted field or one that is hidden from views.

    I also had the same idea as Greg, but organized slightly differently. I was envisioning splitting the process definition into two process definitions:

    1. When an opportunity moves to Closed Won, create a task and set the Description field to your special value.
    2. When a task's status changes to Completed and its Description field = your special value, send an email.

    They seem like they could be considered two distinct flows, and a possible benefit of splitting them is that you won't have processes sitting in progress while waiting for the task to be completed, and will instead trigger a simple process that is immediately completed when the conditions are met.

    Just wanted to throw that out there! I'm not sure if there are any performance implications or really any difference between the combined flow and the separated flows, but if anyone has insight on that, I'd love to hear. Maybe a combined flow is better for easier understanding tracking of the overall progress through the states. Slight smile This is sort of related to the topic being discussed in BPM Best Practice for Start Points - One complex, or multiple simple? What is your opinion? if anyone is interested.

    Thanks.

    -Brenda

Reply
  • 0 Sugar Employee Badge in reply to Armena Ballard

    Just to be clear, the Message Event #1 criteria also has Task Status = Completed, right?

    I just wanted to mention that if you use an editable field (such as Description is OOTB), it is always possible that your special description value won't match because someone else has updated it while you're waiting for the task to be completed. If that's a concern, it would be safer to make your criteria on a field that users can't edit, such as a role-restricted field or one that is hidden from views.

    I also had the same idea as Greg, but organized slightly differently. I was envisioning splitting the process definition into two process definitions:

    1. When an opportunity moves to Closed Won, create a task and set the Description field to your special value.
    2. When a task's status changes to Completed and its Description field = your special value, send an email.

    They seem like they could be considered two distinct flows, and a possible benefit of splitting them is that you won't have processes sitting in progress while waiting for the task to be completed, and will instead trigger a simple process that is immediately completed when the conditions are met.

    Just wanted to throw that out there! I'm not sure if there are any performance implications or really any difference between the combined flow and the separated flows, but if anyone has insight on that, I'd love to hear. Maybe a combined flow is better for easier understanding tracking of the overall progress through the states. Slight smile This is sort of related to the topic being discussed in BPM Best Practice for Start Points - One complex, or multiple simple? What is your opinion? if anyone is interested.

    Thanks.

    -Brenda

Children
  • 0 in reply to Brenda Rossetto

    Thanks for the note, Brenda! 

    You are correct, the Message Event #1 criteria has has Task Status = Completed. And you bring up a good point about the potential for a user to update the description. I'll have to think through that.

    And I was also going back and forth about breaking the workflow into multiple flows, but I decided I'd prefer to have the whole flow together for easier visualization. It's just taking me a few tries to get it right since this is one of the first workflows I've built out!