Loading...
 

Setting up a workflow to accomplish this:

  1. If a trouble ticket is marked as confirm resolution, wait 3 days and send out an email if there has been no modification.

The workflow looks like this:

 

FThEtgqhR_8JsE7uUUAxhMbSReuoWhyGxIPTCWvevYtdyYCrDm789lEnRw4pzdKeJKOIXTopsmsaoIo8Wp9uvHj9uXL8Q28L502n7miCMLCFDP1gsorrh-xkgNfr0WkTb9Qbp7XD

 

where we can see that it will be launched against the Trouble Tickets module every time the record is saved. The workflow will look for the ticket entering the “Wait for Response” status and launch the tasks only when that happens.

It has two email tasks associated which look like this:

 

rNvJzVo82NRhHC35EoIEI7E-wRN8EN98xLOtP9H8Gkg1CskPVLHcQVrW4hTiEEo1ZZ0l2ipfooM2AXI0jMe8_bsPsm8tGfAlTf2ZO7M0dr3DzCfhV0zjigecdcasNyiB9XzDEUYs

 

The important parts here are the 3-day delay in sending and the additional condition. When an email task is evaluated, in this case when the ticket enters “Wait for Response” status, it is automatically put in a queue for it to be sent. Once in the queue, it will ALWAYS be sent. In this case, we tell the system to send it 3 days from “now” so we get our 3 days offset BUT when the day comes we may not want to send it anymore because the ticket has had some changes. In this case we have to add additional conditions on the email itself to detect this case and abort the email if it shouldn't be sent. The condition I use is the “more than hours before” on the modified time and also that the status is still “Wait for Response”. It is possible that just with the last condition we could have enough.

The 4 day offset email is identical but with the 4-day numbers.

  1.  If it is not modified in 4 more days send an email alerting that it will be closed in 24 hours.

This second workflow is a scheduled workflow that launches once a day looking for inactive tickets and closing them after sending an email. That will be two tasks, and update the field tasks to change the status and an email task to send the email. This looks like this:

 

cqKvzNnbEHgCilD56nOLWLbkIgxkvezLDExV61Q-HBUDe1J33LEdPcGvoGMhZ5j_98QGA5GpEi70khmw_ukiCgYocbehC8dj51ShqwiOC3GHVjFZmJYcwfWOvVJpN8Nys_cqFSw7

wu2WPJnSjz3y0282QmOLShjkoDIhCvv1mlvoo9lejDugbz1-dWCSx-kHHXdk_NimYq3vyUZW6vFb1MWmFy-ZCl8x7RbvtG1X1v1x2vu37j5X_PMOkJJAQvglQqZDf4rYZjuGggKb

 

  1. When 15 days remain before the end date of a project a reminder should automatically be sent to its owner (assigned) user reminding him that there are 15 days left. Also when there are 10 left and when there are 5.

Depending on whether you are using coreBOS or coreBOSCRM you have two possibilities:

In coreBOS:

  1. create workflow associated with the project

  2. you add three tasks, each one is executed with a delay of 15, 10 and 5 days compared to the end date

 

image

The downside is that this email will always be sent, that is, if you cancel the project before, you will receive the emails the same. If you change the final date, 3 new emails will be generated for the new date, but the three you have already scheduled will be sent the same.

In coreBOSCRM

You do the same as in coreBOS but you add conditions to the flow and you mark a new option that we have added that is in the conditions of the flow called “Evaluate conditions at the time of execution”

 

image

 

This new option causes the conditions to be evaluated again just at the time of execution. In the case that I propose, if the project has been canceled, the emails will not be sent.

In the case that the execution date has moved, I have not thought about it, but if you put a condition of the type if 15 days are missing today or the end date has changed, it should work. In the case of the creation or change of date the second part of the condition is met and in the case that the mail has to be sent the first part will be fulfilled.

 

image

 

Table of contents:

Admin Manual
Developer Manual