Using Advanced Workflow to identify overdue records

Fairly basic question - is it possible to use Advanced Workflow (Sugar BPM) to follow up overdue records which can currently be done easily in Legacy Workflow.

It seems Advanced Workflow is limited to selecting a specific date rather than for example "before today" or a fixed time span.

For example : Expected Close Date is before today or Task is Due in 5 days time ?

Thanks in advance.

Greg Barrass 

Parents
  • 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! 

Reply
  • 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! 

Children