Jump to content

Victor

Administrators
  • Posts

    5,696
  • Joined

  • Last visited

  • Days Won

    169

Everything posted by Victor

  1. The problem is with the email template used in the BP email node: LogServiceRequest. This template does not exist in the list displayed in: Home -> System -> Email > Templates.
  2. Problem is that you will encounter this issue on the next 160 tickets.... I'll correct this later today, after 17:30 when no analyst are working in the instance.
  3. Just to double check, do you have AR enabled in your instance? This is done via this setting: Home -> System -> Settings -> Advanced : mail.autoresponder.enable - needs to be set to ON.
  4. Not sure I follow this... How is the request reopened? Is it via task completion or an analyst reopens the ticket from call action button? From the current configuration, when the task is completed with "reopen" outcome, it will loop back to, again, the "Await Call Closure" task, but this would be a new task... What exactly does not work with the task timer?
  5. @chriscorcoran what is the BP where you have this behavior? Just wanted to have a quick look at the configuration...
  6. It could be that the email itself fails to meet the rule criteria. What is the exact rule configuration (if different than your above post) and what is the email you tested with?
  7. @Tina.Lapere this should work as far as I know... Can you please send us the details of the issue, with call references if possible where you tested this, and log a support call using: https://www.hornbill.com/request/
  8. @Sean Burke what is the request reference on which you tested this? So we can have a quick look and see what is going on.
  9. @Michael Sharp, we can sort this so you will not have this mix up in any new calls logged but we can't fix the existing ones. If you are happy with this please let us know so we can do this for your instance.
  10. Seems to be related to Hornbill Clean utility not catering for request questions related table. We double check this now.
  11. @Tina.Lapere is it notifications for updates via the portal or notification for autoresponder email updates? As @cchana said, customer portal update notifications is coming in the next release, but other should work fine...
  12. It depends what teams support the service on the request. If only Service Desk team supports the service on the request then you will only have this team available for selection.
  13. We identified the issue recently and a fix will be available in the next Service Manager release.
  14. Yes, that is correct, you would need to choose the "support desk" mailbox Sorry, did not know that I did not test the parallel functionality in much detail... Perhaps have the email node after the parallel processing finishes?
  15. The BPM errors because the "Notify Call Owner" node is missing the value for the mailbox. You would need to switch it from "Auto" to "Manual" and from the dropdown list select the system mailbox (which I think is "Helpdesk"). I have attached a screenshot for easier reference. Also if the all 3 "Notify Call Owner" node are doing the same thing and have the same configuration you might as well use only one as it would be superfluous.
  16. Until or developers and/or product specialists can advise if and when such a functionality will be implemented, perhaps an alternative would be to use routing rules. What I have in mind is something like a rule with the following criteria: subject LIKE '%Out Of Office%' AND fromAddress LIKE '%maildomain%' or subject LIKE '%Out Of Office%' AND fromDomain = 'maildomain' This rule will precede your current update rules and as configuration it will route the email to a mailbox folder. This rule will ensure that any internal OOO will be routed to a folder and not update a call and any external (customer) OOO will be added as update on the call by the other routing rules. You would need to amend the OOO message if is different and use your email domain for 'maildomain'. This being said I can see this not being an alternative if contacts/customers are from within the same organisation which makes the maildomain option unusable for this purpose.
  17. Currently the BP does not allow this functionality. But if there is any plan to allow this, our product managers might be able to give more information. When we would advise for this situation would be to log a new request (based on the existing one) against the correct service.
  18. SR00014224 is assigned to a team (Infrastructure) that you are not a member of. On the other hand, SR00009869 is assigned to "Project" team of which you are a member of. This why one is showing in the list/filter and the other does not. Also the fact that you are the customer on the request does not grant visibility from an analyst perspective, if that makes sense
  19. Probably browser cache still goes for ADFS ...try it with an incognito window or clearing browsing data...
  20. You can bypass the AD authentication or to be more precise use Hornbill authentication by issuing ?ESPBasic=true in your URL. https://live.hornbill.com/<instance_ID>/?ESPBasic=true This will enforce Hornbill authentication rather than SSO.
  21. Your colleague Carl Tiedt logged a call with our support team yesterday in regards to an XMLMC error after a call was logged. During our investigation into this issue we did notice quite many error log entries referring to an 'undefined' mailbox: Operation[mailadmin:sharedMailboxGetInfo] The specified mailbox 'undefined' doesn't exist on the system We found this being cause by a miss-configuration in your instance (as per attached screenshot). As per our email sent to Carl yesterday, we noticed that in Service Manager application settings all notifications were turned on (app.request.notification.*) but the notification mailbox is not currently configured. To have the notifications working correctly and to eliminate the error log entries you would need to either specify the mailbox (which is 'helpdesk') or turn off email notifications (switch notifications from 'both' to 'hornbill-only' or 'none'). Once the correct mailbox is configured you should have the notifications functionality restored (minus the portal update which is currently being fixed).
  22. Actually it seems the issue you experience has a different root cause. The ORC Customercare mailbox - i.e. mailbox_customercare has two associated addresses: "support_copy" and "support". The default one is set currently to "support" (you can check the if you edit the ORC Customer care mailbox and go to "Addresses" tab). I need to have a bit more thorough look into this but it seems to be a defect because the default email address when sending emails should be the address configured as default and not the first address in the list. A quick workaround (if possible in your instance) is to remove (at least for the time being) the "support_copy" email address associated to ORC Customercare mailbox and have only "support"... EDIT: confirmed the mailbox incorrect behavior when having more than one associated address, the source mailbox list will not have the default one as "default". I advised our developers of the issue.
  23. The default mailbox set in your screenshot is used when the email is sent from the mailbox. When the email is sent from within a request then the source mailbox comes from this Service manager application setting: guest.app.requests.notification.emailMailbox
  24. Apologies for the delays Kelvin, we have just replied on the call you logged with Support team
×
×
  • Create New...