Victor
-
Posts
5,696 -
Joined
-
Last visited
-
Days Won
169
Content Type
Profiles
Forums
Enhancement Requests
Posts posted by Victor
-
-
@chriscorcoran what is the BP where you have this behavior? Just wanted to have a quick look at the configuration...
-
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?
-
@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/
-
@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.
-
@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.
-
Seems to be related to Hornbill Clean utility not catering for request questions related table. We double check this now.
-
@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...
-
Just trolling the forums
-
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.
-
We identified the issue recently and a fix will be available in the next Service Manager release.
-
33 minutes ago, Dan Munns said:
I take it the mailbox mentioned in the options is the send from mailbox then?
Yes, that is correct, you would need to choose the "support desk" mailbox
33 minutes ago, Dan Munns said:I tried only having one email notification but as they are in a parallel workflow it gave me an entangled paths error.
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?
-
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.
-
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. -
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. -
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
-
1
-
-
Probably browser cache still goes for ADFS ...try it with an incognito window or clearing browsing data...
-
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. -
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).
-
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.
-
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
-
Apologies for the delays Kelvin, we have just replied on the call you logged with Support team
-
The reason for this is that from a practice perspective, emailing will mean an analyst is doing an action on a call which contradicts with the on-hold status. I know that there is a change that will revamp call statuses to a more usable and meaningful way. Our product specialists will be able to giver you an update on this. I can see that a chase email does not necessarily mean that the analyst is investigating the issue reported in incident or the request made by customer but it would still fall under the rationale. With this in mind perhaps you can achieve the "chase email" via business process to set up tasks that trigger an email when they expire...
EDIT: I can also see the argument that updating a call is an action same as emailing which will also contradict with the on hold status and why is one available and the other not... our product specialists and product managers can explain this in bit more detail.
-
Colin, when did you upgrade Service Manager to latest release?
-
Not necessarily Hornbill specific:
I did not test the parallel functionality in much detail... Perhaps have the email node after the parallel processing finishes?
Automatic close on reopened calls
in Service Manager
Posted
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?