HHH

I like the idea, +1 from us. Of course with the option to opt-out by checkbox the same way as attachments

If I send a link to a request to a customer who is not logged in, for example https://customer.hornbill.com/instancename/servicemanager/request/view/IN00000001 and they click on the link they are stopped by the login page (which is as expected), but after login the customer should be redirected to the request rather than having to search for it or look at their request list to find it again. This is the way Jira or Facebook work and is expected behavior nowadays. Please implement this feature.

Nice idea, perhaps being able to filter to "Subscribers of Services I Support"?

If you add country, please also add language

So do we, I just received a call from one of our local teams

Please add us too

Any news on this @Gerry?

For us it's both since we have seen a tendency for some customers to comment on closed tickets. So +1 from us for this request.

Try using routing rule templates in https://admin.hornbill.com/{instance}/app/com.hornbill.servicemanager/email/auto-log/ Then set up CI and BPM to handle assignment to the specific ticket. (if possible) We have something similar in place although we create new tickets each time.

+1. This may be our most important issue with Service manager ever. That assets cannot be "used" by external organisations

@Victor +1 for your idea to be able to forward/reply to emails from timeline

What is the email template variable name for last timeline update. I want the system to email the update text when an update is made so the customer does not have to log in to see what has been written.

When using variables in emails I can set so it's empty if the Variable does not exist, for example {{Customer Contact.H_jobtitle|empty}} Is it possible to default to a hard coded value instead? Something along the lines of {{Customer Contact.H_jobtitle|"Mr."}} so that if the customer does not have a title the email displays Mr.

This would be helpful for us as well. Currently our second line provides an update and our first line copies this into resolution before resolving it. It would save us a lot of work while at the same time allowing our first line some knowledge transfer on the solution rather than the second line resolving themselves.

We tend to do number 3 informing the customer that the request is related to another service before cancelling. If the request is one that can be resolved quickly it tends to be number 4 with info as above.