Hi Greg Barrass,

shouldn't a CRM system assist a user to avoid situations like that? As a consultant and system designer I would not like to set something like this up that tells me what is already too late. My thinking would be to set up a mechanic that avoids that any date will become overdue so you need a message like "Warning! Your taks is due in 3 days and you have not even started the work" and then "Escalation: Your task has been escalated to person X because you have not started the task 2 day before it is due"

Bests

Björn Canales Pfisterer

Technical Support Manager

provalida GmbH

Hi Greg Barrass,

This linked Knowledge Base article explains how Time-Elapse Workflows function at a database level.

• Both Legacy Workflow and SugarBPM depend on record save to trigger.
• In a time-elapse Legacy Workflow, the initial conditions are met, a new row is written to workflow_schedules with an expiration dateTime, and a scheduler performs actions and alerts when that expiration is in the past.

In Advanced Workflow, a Wait Event in a process definition works similarly. A row is written to the pmse_bpm_flow table when the record hits the Wait Event and that row is given a defined expiration dateTime based on the UI configuration of the Wait Event in the definition. A scheduler will send the record on to the later Actions, etc, the next time it runs following that expiration dateTime. New in 9.0.0, you can set Termination Criteria to terminate the process when the dateTime field changes. If the Start Event is set to respond to all Updates with no other criteria, as one example, a process terminating on field change will immediately re-trigger that process definition, giving your, the process designer, more power to leverage Wait Events based on field values more dynamically.

Process definitions following BPM best practices are intended to be used like flow charts that represent the entire life cycle of a record with delays associated with Wait Events, Receive Message Events, and user Activities after the record has entered the process. In an ideal BPM model, one process definition per module would represent the life cycles of all records and the diverse paths those records can take through your users' work. In comparison, Legacy Workflow is restricted to a one-step condition->action/alert model. 

Patrick,

Thats helpful and I fully understand Legacy Workflow.

How would you design a SugarBPM workflow that, for example, monitors all open tasks and sends email reminders to the assigned users that the task is not complete that is due in 5 days time ?

Regards

Greg Barrass

Hi Greg Barrass,

Here, I answer the Task question in 9.0.0 Enterprise with the simplest process definition I can imagine, fully aware of two considerations:

1. If a Task is created with a Due Date within 5 days of creation, the email will go to the user shortly after creation of the record as the expiration date of the Sleeping Wait Event will be immediately in the past.
2. Scale is a concern. An instance could theoretically hae tens of thousands of open Tasks or process through millions of Tasks in a given quarter of the year. Due to multiple rows being written to the pmse tables in the database for each run of this example process and Sugar not having pruning schedulers built into SugarBPM at this time, the size of the database can grow rather quickly.

The Process Definition Design

1. A Start Events for New Records where Status is not equal to neither Completed nor Deferred.

2. A Start Event for All Updates where Status is not equal neither Completed nor Deferred.

3. A Wait Event for Due Date - 5d

4. A Send Message Event to the Task owner.

5. An End Event that does nothing.

6. Terminate Process criteria reacting to Due Date changes or Status is either Completed or Deferred.

Process Management and the Task

1. Create test Task with Due Date more than 5 days from now.

2. In Process Management, see the In Progress process for this new Task.

3. In database, use this query to see the expiration date of the Sleeping Wait Event

SELECT cas_id, date_entered, cas_due_date FROM pmse_bpm_flow WHERE cas_flow_status LIKE 'SLEEPING';

4. Edit the Task, changing the Due Date.

5. In Process Management, see the previous process Terminated and a new process In Progress.

6. In database, see the expiration date of the Sleeping Wait Event.

7. Edit the Task, changing status to Completed.

8. In Process Management, see the process Terminated

I hope this helps!

This is excellent Patrick - it will definitely help me and hope it is of benefit to others in this forum. I'll try it out later today.

Regards

Greg Barrass

@patrickmcqueen - I noticed the Step #2 Event includes the "and" operator vs. "or" ~

Since this workflow is very similar to some we are having difficulty with at the moment, I am looking into each portion to see where the fails might be. We are currently using "or" to identify which fields the Status cannot be. How big a difference can this make in the disruption of a workflow in your estimation? advanced workflows logic admin

Hi Patrick

Thanks for your clear steps-by-steps response. I try on my side and everything works well except when the task due date is updated. The current process is terminaded as expected but there is no new process in progress created (step 5 in your post). I try with version 9.0 and version 9.2 with the same result. 

Any idea of what is going on ?

Regards

Pierre

Hi Pierre Bourban,

Sugar has evolved a bit since I wrote the above response.

I now believe the loops I built into the stock Case Follow-Up Date Management process definition are a better approach to assessing and responding to changes in date fields.

The loop leverages an Event-based gateway that sets a race condition between Wait Event(s) and Receive Message Event(s), as shown here:

The above was developed in consideration that a Wait Event does not update if the date used in the criteria changes on the record. The Receive Message event, waiting for any change to the date field, will escape the Wait Event if the date is changed, then simply loop back into the event-based gateway which will automatically re-trigger the Wait Event with the new date value.

I hope this helps! 

Hi Pierre Bourban,

Sugar has evolved a bit since I wrote the above response.

I now believe the loops I built into the stock Case Follow-Up Date Management process definition are a better approach to assessing and responding to changes in date fields.

The loop leverages an Event-based gateway that sets a race condition between Wait Event(s) and Receive Message Event(s), as shown here:

The above was developed in consideration that a Wait Event does not update if the date used in the criteria changes on the record. The Receive Message event, waiting for any change to the date field, will escape the Wait Event if the date is changed, then simply loop back into the event-based gateway which will automatically re-trigger the Wait Event with the new date value.

I hope this helps! 

Hi Patrick

You're right. It works perfectly by adding an event-based gateway and a receive message event. 

Thanks a lot

Regards

Pierre

hi Patrick McQueen
Do you have a simpler example on using Event-based gateway like when a meeting or call date changes to send notification to related contacts? 

Hi Vincent Amari,

I hope this helps.

Hi Patrick McQueen
Appreciate that. Excuse my ignorance on the Event based gateway, could your example be easily included as part of a 'complete' process (as attached) that starts as a custom message to all Guests within a Meeting or Call, or does it need to stay as a separate process?

And is the 1 hour Wait you added used as 'best practice?

Meeting_confirmation.bpm.zip

Hi Vincent Amari,

The Wait Time was arbitrary. It's up to you.

Yes, the approach can be added to an existing process, as shown here using your provided process.

Great, thank you Patrick McQueen
Final point that I think would help many here, because the message will include a date/time of the scheduled Meeting or Call, can we exclude any 'overdue' as otherwise the messages would not make sense?

Using Calculated fields to flag these and use as criteria is easy enough, but we have no guarantee that the field get's updated.

Hi Vincent Amari,

The calculated custom field is a great idea!

From my perspective, this follow-up question ventures beyond this discussion at hand into other aspects of Sugar not specific to the idea presented here.

There is not, at this time, a stock way of tagging a meeting/call as overdue. You are correct that a custom calculated field could be used for such a thing. Since the Receive Message Event, like the calculated field, depend on a save event occurring, I believe the approach of using that custom field as criteria would work. Any issue with the calculated field updating sounds like a problem with the calculated field configuration or feature.

Hi Patrick McQueen
Calculated field option seems to work fine, as described in my reply to Yury Voloshin today.
Thanks again for helping to brainstorm solutions