Jump to content

Victor

Administrators
  • Content count

    1,355
  • Joined

  • Last visited

  • Days Won

    22

Victor last won the day on November 13

Victor had the most liked content!

Community Reputation

117 Excellent

2 Followers

About Victor

  • Rank
    Senior Member

Profile Information

  • Gender
    Male

Recent Profile Visitors

803 profile views
  1. Oh, I missed this bit of information, sorry ... I'll have a look...
  2. @Harry The "live.hornbill.com" outgoing route in your instance is used exclusively to send out these notifications. It won't be used for anything else. The analystneeds to use the email action (the "envelope") on the request in order for the customer to get an email
  3. @Harry sorry, I am still confused, so backtracking our conversation: You mentioned this: "When a customer sends an update on a ticket, I don't get any notification in the top right corner or email notifications.". You confirmed the update is made by customer via customer portal. In this case, this how this works: "analyst (email) notifications for updates made by customer on the customer portal will be sent using "live.hornbill.com" and will have the from address as "no-reply@live.hornbill.com". This is not something that can be configured anywhere at the moment, it is hard coded." So you need to enable the setting(s) I mentioned before plus have the "live.hornbill.com" outbound route configured in your instance.
  4. @Harry analyst (email) notifications for updates made by customer on the customer portal will be sent using "live.hornbill.com" and will have the from address as "no-reply@live.hornbill.com". This is not something that can be configured anywhere at the moment, it is hard coded. Sorry, I was thinking we are talking about analyst notifications?
  5. @Harry the "live.hornbill.com" mail routing in your instances is not configured to use direct outbound. Can you please change the routing mode to "Use Direct Outbound" for the "live.hornbill.com" domain? Let me know if the notification issue still persists afterwards...
  6. Breach Emails

    @yelyah.nodrog this is something @James Ainsworth or @Steven Boardman can advise on...
  7. @Harry do you have this outbound routing rule configured in your instance? Notifications for portal updates require this...
  8. System Autoresponder

    @yelyah.nodrog this bounce back message is generated by your mail server, nothing to do with Hornbill. This needs to be investigated by your mail server administrators. You also have a routing rule in place which will automatically update requests with the bounce back message. The automatic update will in return generate a Hornbill email notification to analysts. So what needs to be done (imo): 1. Liaise with your mail server admin to investigate why the "undeliverable" bounce back messages occur 2. Amend your routing rules to exclude these "undeliverable" bounce back messages from being applied to requests. Note: I would advise editing your original post to remove sensitive information (such as email addresses). I kindly remind you our forums are publicly accessible. Only registered users can create new threads, however, anyone can see the forum threads, so information posted by our users can be seen by anyone (not only our registered users)...
  9. @Harry have you enabled customer portal notifications?
  10. @Harry how did the customer send the update? Was it an email applied to the request? If yes, was it applied automatically by routing rules or by an analyst? Was the update made via the customer portal?
  11. Breach Emails

    @yelyah.nodrog I can confirm the above posted by Martyn. Currently, you can only set reminders for owner or owner's manager.
  12. Routing Rules

    @Giuseppe Iannacone no worries
  13. Routing Rules

    @Giuseppe Iannacone you sure you have the right configuration?
  14. Access to calls from redundant services

    @paul_rbbc does the redundant service have any catalog items configured? I am thinking you can have the redundant service with portal visibility On... as it does not have any catalog items it won't be displayed on the portal but because the portal visibility is On, it should grant access to requests against the service... I haven't tried this configuration though... EDIT: on a second thought, what I think it would happen though, is that the service will be visible on portal but no one will be able to raise new requests against it since it won't have any catalog items (you could also make the catalog items "Service Desk" only, instead of removing them which would be a preferred option)
  15. Can't View Requests for certain teams

    @SJEaton right, I thought something like this might do the trick So, just to make things a bit more clear, and explain why this worked and why it might look "weird" ( ) when creating custom views, if your criteria does not include teams or service, Hornbill will apply the default visibility restrictions as per your current service configuration: if your custom view does not have a team criterion, the view results will be automatically filtered to exclude requests raised against a team of which the user is not a member of. if your custom view does not have service criterion, the view results will be automatically filtered to exclude requests raised against services which the user's teams are not supporting; These filters are applied by default in addition to whatever criteria is specified in the custom view, of course, this is if the conditions are met (i.e. custom view does not have a team criteria and/or custom view does not have service criteria)
×