Process Definition for Changing Status when Tasks are Completed

Hello Casey Henry#,

It sounds like you need to use Receive Message events. I like to call these "listen for change" events. They basically behave like a Wait event but wait for some change to happen instead of waiting until a specified time/date. Alternatively, for more complex processes like this one, it may benefit you to create a Process Business Rule. Then you can simply evaluate the return value of the rule and have a less complicated Process Definition. 

Check out this article, which explains both methods: Triggering on "To" and "From" Field Values in Advanced Workflow

process author advanced workflow process business rule process definition

Using the Receive Message worked. Thanks for your help, Jill Shaheen. Where can I go to learn when to use Business Rules versus Definitions? I can't seem to find a straight forward explanation in the knowledge base.

Casey Henry

That's a tricky one... sometimes it will simply be the admin's preference. Because Business Rules are a standard BPMN element, there is a lot of documentation you can find outside of Sugar's support site by searching for "BPMN business rule." 

I would consider these scenarios for using a rule:

• The pd is already massively complex and you'd rather insert a simple business rule action than build out more functionality within the pd.
• You have many process definitions that use the same logic and it would be easier to manage the logic from a central location (think of the rule as a style sheet that can be used by multiple process definitions).
• You need to create a gateway element that has more than 4 potential outcomes. Scenarios that have a lot of if-this/then-thats are good candidates for a business rule.

Casey Henry

That's a tricky one... sometimes it will simply be the admin's preference. Because Business Rules are a standard BPMN element, there is a lot of documentation you can find outside of Sugar's support site by searching for "BPMN business rule." 

I would consider these scenarios for using a rule:

• The pd is already massively complex and you'd rather insert a simple business rule action than build out more functionality within the pd.
• You have many process definitions that use the same logic and it would be easier to manage the logic from a central location (think of the rule as a style sheet that can be used by multiple process definitions).
• You need to create a gateway element that has more than 4 potential outcomes. Scenarios that have a lot of if-this/then-thats are good candidates for a business rule.