Can I suspend/stop emails going out from an already-executed BP as we tidy data?

[Berto2002]

We have a workflow that broke some time ago; it gets stuck midway through waiting for something. It didn't stop our agents completing the work and resolving the Request, though... The manual workaround of completing that action is something we can handle but at the end of the process, the BP is configured to email the Customer with the Resolution details (even though they received those, say, 3 weeks ago).

We don't want to scare people by sending them the same information again such as "I have reset your password" or "So-and-so has been deleted".

Can anyone help with how we can suppress these emails without manually editing the Executed process for every one of them? Off the wall examples: can we hard-code the recipient in the email template so it overrides the variable from the BP so diverts emails to a trash mailbox, can we configure the mailbox to reject/ignore emails from a certain named process for a period, can we filter those out before they get sent using another mechanism, can we turn off email sending for a period and it will discard not cache them for later, etc??

Thank you!

[Conor]

Hi @Berto2002

The easiest way would be to simply resolve/close/cancel the requests. This will stop the BP from progressing and then sending the resolution emails. 

If these actions are locked in the BP (and so the only way to resolve/close is to progress the BP) then it may be possible to stop the outbound mail while you tidy up, and then remove these outbound mail items from the outbox before turning the outbound mail back on, but I wouldn't recommend that as it would also affect any other emails that may be going out at the same time. 

[Steve Giller]

30 minutes ago, Berto2002 said:

without manually editing the Executed process for every one of them

This is the key point - you can't do that. When a Request is raised it has its own Instance of the Workflow, there is no way to bulk edit these as they are discrete objects.

[Berto2002]

@Conor, would would I stop the outbound mail while I tidy-up and leave the items in the Hornbill mailbox so they can be deleted before they go? Can you show in pictures or describe the parts of the system to alter?

We are trying to do this cleanly. The Requests are already resolved. If we force Close, the workflow remains indefinitely in the Suspended state. Only if we get the workflow to close do we avoid having hundreds of permanently suspended workflows.

[Berto2002]

@Steve Giller. Indeed and I see why it's own instance is used.

However, as an aside, there's an (annoying) anomaly here. When you attempt to rename a Business Process, you can only do so if there are NO active instances (i.e. no Un-closed Requests) of that workflow in flight. Which in practical terms you can never rename a heavily-used core workflow because you'll never have all your incidents or problems closed. And yet, logically, this is should not apply, because each Request you open takes it's own 'copy' and should be running within that; so the rename should be possible...

[Berto2002]

Both, I am working with the email team to see if we can filter them out at the receiving end...

[Conor]

@Berto2002 if the key thing is to remove the suspended workflows you could simply delete the relevant workflow instances from the Executed Processes list? The best way will be to stop the requests from getting to the point of sending emails, rather than trying to temporarily stop all outbound emails

[Steve Giller]

@Berto2002 With regards to not deleting/renaming the BP, you can deactivate the Business Process, which by default removes it from the list.

[Berto2002]

We've stumbled upon a useful feature here. All our users are 'internal' to the organisation so we have the same email system so we can control receipt. We've put a filter on our inbound email to block and delete all inbound emails with "DoNotSendEmailNotifications" string in the subject or body. We've added a snippet in HBSM that SDesk can use at any time to suppress the automated email for any reason. It also means we can now do our data fix and though SM sends emails, they won't be received.