Enhancement: Please allow Request Updates to Users to be configured to go out through platforms other than email

[Berto2002]

We are moving away from email. I am piloting a system that allows users to alter their comms preferences by selecting an option on a simple IC form to have "Teams" or "Email". This updates Attribute 6 of their Profile with a string. The IN and SR BPM's read that string at the start and end of the workflow to decide if the BPM sends the email or uses a cloud node to private message the User with the logging / resolution notification.

I have a big blocker, though, in two core areas.

1. I cannot control the notifications for the Update of Requests which are hard-coded as email-only. Yes, I can turn on or off email updates by service but I cannot choose another platform
2. In Requests, we have an Email action or we can (as above) have emails sent for TimeLine updates but I have no option in the UI to communicate with my Users on Requests through another platform

In a world where collaboration platforms are booming and proving themselves effective, users and CEOs want to reduce emails, I suggest there is a strong case for Hornbill to provide options for Updates to Requests to be sent out through other platforms/integrations

 I previously skirted around this topic in this chat but would like to be more pointed in this post and directly ask for this enhancement to be put on the roadmap as it's going to become an issue for us now our new CEO has asked everyone to reduce email dependency and up our game on using Teams collaboratively.

 

[Steve Giller]

I have asked if any Developers could comment on this.

I am, of course, honour-bound to point out that this is the whole point of Hornbill Collaboration - it allows your Users to see everything in one place without needing to resort to emails etc.

[Gerry]

@Berto2002

For the places in Hornbill that use Email there is not always a direct translation to other channels.  For example, we have in the user profile a users email address, we do not have any place to put a teams ID or any internal knowledge of the teams system, and how email message formatting, to/cc/bcc and subject, template formatting and other email specific things in the context of teams, which is not an email system.  Not everyone uses Teams, some people use Slack, others even use Hornbill, and there are many other such alternative systems to email that companies have been rolling out for a number of years.  

To address this properly we would effectively have to abandon on the notion of email notifications/communication in the context of requests and genericise the UI and feature set in relation to notifications/manual updates to work with multiple communications channels such as Slack, Teams, Jira, Hornbill and other collaboration-like tools as well as email.   There is a lot to that, its not a simple change.  The alternative might be to leave the email behaviour exactly as is, and add a second option for other channels. 

I will add to the list of things to review and consider for a future change/enhancement, but this will not be a quick thing to address. 

Gerry 

[Berto2002]

Thanks @Gerry I recognise this is a big thing to consider and thus important to have on your radar.

Your system almost ready has the pre-reqs in place for this "second option":

1. There is already a method that detects Customer Visibility Updates on Requests
2. There are already integrations to other platforms through iBridge
3. There are already ad-hoc BPMs that can run on Requests (Autotasks)

Excuse what may be a hopeless suggestion to make this 'easy' but this is what is on my mind, without knowing your architecture details tho:

1. A new Application Configuration option in Service Manager called "TriggerAutoTaskOnCustomerRequestUpdate" with a field for the name of the Autotask to be fired. That enables the named AutoTask to trigger under the same criteria as the application currently already triggers the Email Update
2. Enable Cloud nodes in AutoTasks

That allows us admins to have an Autotask that does almost anything on Customer Visibility Update but specifically in this case I would have it:

• GetRequest Information
• Get Customer Information
• Check if Customer is the same as the value of a defined Custom field and use this to confirm if existing Message ID could be used or needs to be restarted as a conversation with new Customer if has altered
• Check Request Custom field value for pre-existing Message ID
• If no Message ID or Customer has altered, create new Message to Channel/Team and store Message ID value in Custom Field
• Using the new or existing Message ID to Reply to Message with some "you have an update" kind of text
• Update Custom field with new Customer for next time
• End

We could include options on that AutoTask to only fire for certain Services or Users. I already have BPM to allow users to opt-in or out of Teams updates for their New Request and Resolutions using a flag in a custom field on the Users Profile so I would use that here also.

I would then disable/remove the email updates on services where we did not want both.

Provided other platforms were also available on the Cloud nodes, they could do the same.

Just some thoughts.

[Gerry]

@Berto2002

Thanks for the suggestions, I will make sure to tag this and consider options. 

 

Gerry