Email Routing Rules - visibility Override

[Martyn Houghton]

At the moment there is a system wide setting which set the visibility of the timeline entry of an email update applied automatically to the Service Manager request by the Email Routing Rules, however it would be really useful to be able to override this setting at the rule level if required.

In our case we have the setting set to customer, so when an email is received with a matching request reference in the email subject the request is automatically updated with the customer view able entry. However for internal emails, i.e. where we would use the 'domain' criteria in the rule criteria, we would not want them to appear as customer view able updates and therefore would want to override the default to make them team visibility.

As it stands at the moment we have filter out the internal emails and update them manually.

Hopefully this could be looked at as a enhancement, as i think this would be useful to other users as well.

Cheers

Martyn

[Martyn Houghton]

@James Ainsworth

Is there any update on this? Without the ability to control visibility on the rules, we cannot implement two way integration with updating of requests from third party system as these updates would be customer viewable, as we also use Auto responders for customer logging and updating emails.

Cheers

Martyn

[HHH]

+1. This is a major issue for us too with regards to both third party system integration as well as having third party staff "consult" in a ticket through emails. 

[Martyn Houghton]

@James Ainsworth

This is really becoming a barrier to us automating interfaces both internally and externally. We can use iBridge to initiate things, but cannot automate the updates back via email, as we cannot override the default visibility to Team.

Can this be reviewed and escalated please.

Cheers

Martyn

[Martyn Houghton]

@James Ainsworth

Any update on this critical enhancement?

Cheers

Martyn

[HHH]

@James Ainsworth
Same question as @Martyn Houghton, any news on this?

[Martyn Houghton]

@James Ainsworth @Steven Boardman

Any update on this?

This is essential for us undertaken external customer facing service desks.

Cheers

Martyn

[Steve Giller]

The logical thing to do here would be to put privacy first and set the default to Team, changing to Customer if required.

That way you can push on with the actions that require the updates to not be customer-facing without compromising privacy.

[Martyn Houghton]

@Steve Giller

Being an external customer facing service desk, we default everything to customer visible, so no matter what time of the day they update the requests the customer updates show on the portal. Due to the volume of emails and requests we are talking about we need to be able to do this based on the rules, rather then relying on an analyst remembering to go back to the email timeline update and change the customer visibility and potentially others actions triggered by the email update in the workflow.

Unfortunately one rule does not fit all.

Cheers

Martyn

 

[Martyn Houghton]

@James Ainsworth @Steven Boardman

Is there any update on this please?

Cheers

Martyn

[samwoo]

+1 for this

[Martyn Houghton]

Hornbill

Any update on this?

Cheers

Martyn

[Martyn Houghton]

@Harry Hornbill

Any update on this?

Cheers

Martyn

[Paul Chambers]

Hi
Is there any update on this ?
We have examples where human error has meant that emails meant for internal (team) visibility have been left as customer visible (the email update timeline post has not been manually updated).
Also, only the person who has administered the update, or a user with sysadmin access can update the visibility which leads to delays in being able to change visibility where human errors have occurred.
This is exacerbated when the update is via auto responder, and only a user with sysadmin access can update the visibility.
Thanks in advance 
FYI @samwoo @HHH
 

[Gerry]

@Martyn Houghton

I see this has been an ongoing requirement for a long time, I just wanted to clarify my understanding here. You have suggested that this be implemented "at the rule level" but from an implementation point of view, this is not possible (see below for an expansion on this), because, the email routing rules system is a generic, generalized platform capability that does the rule logic and then invokes an application-specific function, in this case, Service Manager.  So to meet this requirement there is really two quite independent things that need to be done

1. The first thing is, that the input params that the Email Routing Rules passes to the application function is a fixed set of email-related fields (to, cc, bcc, subject, etc). In order to allow you to set rule-trigger specific options, it would be ideal if, when creating an AR function in an application, for example, the ones in Service Manager, that the application devs could also present *addtional* input parameter requirements.  In the Rule properties, these addtional input parameters could be presented to you such that when configuring the rule, you could provide the required value.  One such input field *could* be the visibility of the item in the timeline.  So the first thing would be to extend the rules system to allow for these addtional parameters to be defined.  There is another requirement we have that would also be met by this addtional params at config time extension, so that discussion was already in play

2. The second thing would be for the Service Manager dev team to extend the AR related request hadlers to present the required addtional params and functionallity - easy enough to do with the rules supporting point 1 above

Some design work needs to be done to implement point 1 above, but there is an ongoing discussion around this internally. Once thats done then point 2 would be an easy requirement to meet

Gerry

[Martyn Houghton]

@Gerry

Thanks for the detailed response. In essence from a UI point of the 'Operation' select of 'Update request' would remain and work as current based on the system wide visibility setting but be completmented with 'Update request Customer Viewable' and 'Update request Team Viewable'. With these applying the visibility of the timeline update/attachments as indicated by the name of the operation irrespective of the current system setting.

Cheers

Martyn

[Martyn Houghton]

@Gerry

Any further thoughts on this one?

Cheers

Martyn

[Gerry]

Hi Martyn,

Thanks for the reminder.  I had to go back and look before responding.  So this is the position so far.  We did, a very long time ago make it possible for each application to "extend" the UI in the Auto Responder rule properties to add addtional information.  You will see this in action when, for example, you select an action that requires you to select a specific template, in this case, the generic Reference field is refactored to become a drop-down list of templates for you to select from, that drop-down is the application operation specific custom property.   In practice, its possible for each application team to show whatever addtional information they like here, which can include a theoretically endless number of fields for addtional information that is passed to the underlying operation, the one limitation here is, the Reference field stored in the database only has a capacity of 64 characters.  So based on my last comment above about being two sets of things that need to happen, the first thing needed has already been done.  This means that I need to pass over to the Service Manager team to do the second, I expect this might already have been on the backlog, I will need to check, and I will ask someone from the SM dev team to follow up here. 

All that being said, having had a quick review of the function as is today with a developer, I do want to make a couple of different improvements, which are simple, and now in the works...

• I am going to expand the capacity of the field that holds the addtional custom information from 64 to 2048 characters, that should be enough to allow for simple JSON structures, CSV's or any other text based multi-value property construct, giving the application team more flexibility as to what they can bring through into settings
• By default, if an application auto responder operation does not provide custom properties, we show the Reference field by default.  In most cases there is no use for this, so we are going to hide that by default so its less confusing, each Auto Responder operation that needs the reference field can resurface it, which will make things easier for anyone configuring these.  
• I am going to arrange for the UI of the Email Routing Rule properties to be slightly re-organised such that the Reference field is removed (as above) and, when there are custom config properties these will be shown in a separate form section, and I will encourage the app team(s) to include in their custom properties area an in-app help popup, like we have already provided for the expression. 

These changes are trivial, so will get them done over the next couple of weeks, and I will ask the SM team to look at tihs requirement with a view to making use of the above. 

 

Hope thats helpful

Gerry

 

[AlexTumber]

@Martyn Houghton @HHH @samwoo @Paul Chambers I'm just catching up on this thread.

Please correct me if I'm wrong but if we were to add the ability to choose timeline post visibility to an email routing rule template, would that work for everyone's use cases?

Alex

Quick mockup:

[Paul Chambers]

Hi @AlexTumber
That will work for us as per info previously supplied by @Martyn Houghton

We would then configure multiple inbound routing rules based on whether the email address was internal (Team Visibility) or external (Customer Visibility) to our organisaiton.
Thanks in advance.

[AlexTumber]

@Paul Chambers thanks for that. It confirms what I was thinking

 

Alex

[Martyn Houghton]

@AlexTumber

Just checking the option to override visibility is applicable to both the 'Rasie new request' and the 'Update request' operations, as the screenshot appears to relate to a template used by the 'Raise new request' operation.

The reason for having on 'Update request' is we are using email updates to bring in and trigger the BPM in relation to Enterprise Service Management actions happening outside of Hornbill.

Cheers

Martyn

[AlexTumber]

@Martyn Houghton yes just to confirm this will be the case for any operation that uses a routing rule template.

Alex

[Martyn Houghton]

@AlexTumber

Might be wrong but I thought the 'Update request' option at this time does not use a routing rule template

 

Cheers

Martyn

[HHH]

@AlexTumber If it works for updates as well as raising requests it would work for us but I share @Martyn Houghton's concern regarding  "Update request" not using email templates since this is where we would have the most use for hiding the email from customers where information in email is internal.