Mike Hillman
-
Posts
52 -
Joined
-
Last visited
Content Type
Profiles
Forums
Enhancement Requests
Posts posted by Mike Hillman
-
-
On 23/04/2024 at 10:39, Mike Hillman said:
We're seeing this too, although not very often as yet - last occurred at the end of last week
I've now had several other instances of the workflow crashing on Lock Actions over yesterday and today
-
We're seeing this too, although not very often as yet - last occurred at the end of last week
-
29 minutes ago, Steve Giller said:
You cannot "force" a Workflow past a Suspended state.
I would suggest having a shorter expiry time, if the waiting for the expiry is what's annoying your customer(s).This is a bit of a shame if I'm being honest - shortening the expiry isn't really an option, they're set to what they are for operational reasons
I can think of a number of situations where, with the best will in the world, we've tried not to set the expiry to wait for too long but something out of the ordinary crops up which causes us to have to try and progress the ticket more quickly, especially with the nature of our work - as it stands we end up having to work outside of the ticket and add all the notes etc when the ticket catches up, which isn't ideal as our agents are already pretty overloaded so this tends to get forgotten. Digging out the email from the sent items and actioning it ourselves, again in our environment, is generally a no-no for various reasonsBeing able to manually override a suspended workflow to get it to forget whatever it's waiting for and just get moving again would be extremely useful to get us out of the issues without having to fudge round them
-
Not sure if anyone had any ideas on this one
We use the External Authorisation node in workflows to send approval requests - I set it to expire after 3 days, after which it loops back round, prompts the agent to confirm the approver is still right, gives them a chance to change it if needed and resends the email to prompt the approver again
A problem we get frequently is that once the approver has been entered and the Authorisation email sent, the customer comes back and tells us that approver has left/moved/changed/off sick/on leave (delete as appropriate). We then have a list of secondary approvers we can fall back on, however the issue we have is that the workflow is suspended pending the approver responding to the email (which they won't as they're not there) or until it expires (which is 3 days away, and the customer won't wait that long, so we get a lot of shouty nagging)
so my question is - is there anyway, via perhaps a custom button, that we can bring a suspended workflow back to being active ahead of the expiry in this scenario, so we can continue processing (i.e. loop things back round, amend the approver and send the email again) without having to wait it out or wait for an approval action we know isn't going to come? -
Many thanks, seems to be working for us again now, thanks for your assistance
- 1
-
thanks - I've just tested the comments myself and they seem to be working, so that might have been a connection dropout on our side
Thanks for the update ref the statuses, that does match with what we're seeing
-
Thanks for this - no, it doesn't appear when the browser is refreshed - I've captured a HAR file attempting to change a status, but it's 21Mb so over the file size limit for Direct Message
I am leaning towards this being an issue our end somewhere, but it's behaviour we've not seen before -
We've noticed some issues this morning with both posting comments onto requests and also changing request statuses - we don't seem to be able to do either, Hornbill just sits there
Just wondering if anyone else is having similar issues? We have had some internal firewall/connection issues in the past which have caused issues with Hornbill, I'm trying to narrow down if this might be a Hornbill issue or an internal connectivity issue, especially bearing in mind the update which has just been applied
-
Charts are working again for me this morning, and they appear to be showing correct data
-
3 hours ago, Steve Giller said:
A patch has been deployed and this issue should now be resolved.
@Mike Hillman Could you also let us know if the "not loading" issue was resolved by this as well, please?
Just wondering if there's any further news on this - charts are still not loading for me
-
11 minutes ago, Steve Giller said:
A patch has been deployed and this issue should now be resolved.
@Mike Hillman Could you also let us know if the "not loading" issue was resolved by this as well, please?
Doesn't appear to have I'm afraid, still not loading at the moment
-
5 minutes ago, Steve Giller said:
@Mike Hillman To clarify, where the charts are not loading, the underlying issue is likely to be same, but the unexpectedly high amount of data is causing the action to time out.
I did suspect that might be what was happening - thanks
-
Just now, David Hall said:
Thanks for posting, we are currently investigating high numbers of results in charts and will provide an update as soon possible.
Kind regards,
Dave
Thanks - will keep an eye out. Will this also include the issue with them not displaying at all?
-
3 minutes ago, Jim said:
Ours show some very inflated figures after the update
That's the issue our manager is getting - apparently, one member of staff resolved 8000 tickets last week - which is even more impressive given that they left 2 years ago!
-
-
On 7/13/2023 at 3:08 PM, Steve Giller said:
Well, that's a rather obvious fact I've totally missed! Shows how often I use them.... my fault for assuming!
In some ways that's even worse, it means people are individually opening tickets to change the status, and ignoring the replies and updates in the timeline....
not to worry, many thanks
-
Not sure if this is possible - I'm having some issues where I suspect some of my staff are using the Request Actions in the Request List to place tickets into On Hold statuses in bulk, in order to make it appear that they have been updated, when they've not actually followed up properly on the tickets individually as they should be
Is there any way to restrict who can access/use the Request Actions? I'd like to restrict them so my 1st Line Team can't access or use them (as there isn't a reason for them to bulk update tickets)
-
Seems to be back up again now here as well
-
Same here as well
-
+1 here too
-
1 hour ago, Adrian Simpkins said:
Thanks - we'd spied the option on the individual profile for each user so we've removed a few, but it doesn't look like there's a way to do it in bulk
I think I'll have to take the user education route!Cheers
- 1
-
I think this one fits under Collaboration
We're looking for a way to remove, and ideally block people from adding, the profile photos against the Hornbill profiles for our employees
We're basically having a problem with people using all sorts of images (Football Team badges, pets, cars, all sorts) as their profile picture - our exec team have flagged this as being unprofessional given the nature of what we do and would like us to remove them
Short of contacting all users directly to request removal, I was hoping there's a way within Hornbill to bulk remove them and block people from adding them but I've had a good look and can't find anything -
4 hours ago, Jeremy said:
Also today we have noticed that custom fields that are set in the IC are not being transferred into the request, so we are seeing some of our business processes failing.
Has there been an update to the ICs recently that is causing these issues?
We've noticed the same today as well - all our business processes rely on this, so it's causing a lot of errors and issues. Summary and Descriptions are also not being pulled over in some cases, as well as custom fields
I don't believe we've been seeing the error pop up on the ICs though, but I'm going to do some testing -
We've noticed the same issue this morning with Labels - I thought it was linked to a bug we've already been experiencing on PCFs so I tagged it into the Thread I've already got open for that one
Error Code 1 - Could not connect to Server
in Service Manager
Posted
Not sure if this will help you work out where the issue lies, but we experience this issue quite frequently - in our case I am fairly certain it's down to our network infrastructure/internet connection, as whenever we notice the issue occurring if I test access to Hornbill on my own personal PC at home if I'm working remotely (avoiding our VPN and network) or via 4G on my mobile it works absolutely fine, so I don't think it's an issue on the Hornbill side
When it occurs for us it tend to affect everyone, but only lasts for a few seconds each time