re-generate configurable notifciations

Nicole Novack 1 year ago in Productivity Management updated by Matt Chabot 1 year ago 3

Once notifications are issued through a workflow action, end users have reported receiving said notification. Having the ability to re-generate a previously generated notification is needed to ensure critical compliance related steps are met in the event they are lost in cyber space.

Let me know if I do not understand your asks correctly, but I see two potential workarounds that might help.  We used to have a big problem with this, especially for compliance related tasks that we needed complete within a certain timeframe (10 days).  Our old process was to run a report and message the Assignees directly at the end of each week which was exhaustive.  

Solution 1: Easy Implementation, Limited Customization

When I rebuilt our workflows, I set the compliance workflow step (via workflow designer) so the default Task Reminder notification would send out after +3 days and continue to send out every +3 days after that. If the time restricted task got to +7 days past its due date/"End Date", we used the Task Escalation functionality to send out a separate email to the Project Manager, which in our case is our support team.  The support team would then reach out to the assignee directly to determine the reason for the delay.

If you're interested in just bugging the Assignee like in our case, this method would probably work best as it is easy to implement.  On the other hand, while you can customize these default notifications, they're the only two templates you have to work with for reminders across all steps/reviews.  We chose to go with general templates as we implemented this functionality (with varying time intervals) across all of our steps and have seen great results.

Note: You do have the option to set the Escalate To: receiver as the Assignee or the Assignee & Project Manager as well.  Also, the Escalate notification does not repeat on an interval like the reminder notification.

Solution 2: Difficult Implementation, Full Customization

The other option you have is to use a status action on an iterating auto-close (AC) step that runs in tandem with your compliance step.  The workflow would split off in two directions after whichever predecessor step closed.  Based on an output port rule that would never trigger or trigger after a certain number of iterations, the autoclose step/iterating notification subworkflow (upper portion) would continue to iterate, say every +1 days, until the compliance step (lower portion) was closed.  Two input ports would be set on the next step in the workflow with the one connecting to the Compliance Step (lower one) being the only one set to required.  This way, you have a valid workflow with a closed loop, but the workflow will not wait for the iterating subworkflow, only the compliance step.  This would allow you to have full control over what notifications are sent on an iterating basis, but in my opinion, it would add a level of complexity that probably isn't worth the trouble.  

Sorry for the length of my response, but I hope this helps and let me know if you have any questions.



My required use case is for notifications which are configured and send out through status actions on a task, but agree that base notifications that are issued with Reviews would also be a benefit. 

I'd just add that we would likely want to suppress the original distribution list and be able to target the recipients when re-sending.

Would this be for task assignment notifications or a review task with the approve/reject vote and reviewer comments?  I think it would be nice to be able to resend the review notifications by going into the closed task and the system admin having an option to resend but I would not want my end users to have the ability.