Jump to content

James Gallally

Hornbill Users
  • Posts

    74
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by James Gallally

  1. Good afternoon, We are using activity templates to create set check-lists for some incidents, and am having issues with people not having access to said activities. Our manager and team leaders are going in and adding activities to incidents, but by default it is automatically assigning the activity to them and not the owner of the incident. I have checked, and when the new activity is assigned, you can assign the owner here but by default the option is hidden and has to be enabled under advanced options (people forget to check/set). Can I either set it so that the owner is automatically taken from the incident that the activity is assigned to or can I set it so that the owner option is automatically displayed by default when the activity is assigned? Thanks James
  2. +1 - we had https://live.hornbill.com/ become unavailable for 5 minutes
  3. Thanks @Steven Boardman, I have tweaked your example and it works exactly like I was hoping. Just need to figure out the daylight saving part. Thanks
  4. Thanks for the explanation @Steve Giller, I had seen a similar value whilst testing different options and couldn't understand how it was arrived at. Thanks @Steven Boardman that looks almost exactly what I am trying to achieve, I'll have a look at seeing if I can replicate it. Thanks both for your help. James
  5. Good afternoon, I am trying to get a BPM decision to work based on what time an incident was logged. The purpose is so that when it happens out of hours a set of actions gets triggered that don't normally happen in hours. I thought it looked simple enough until I found out that the Hornbill Automations -> Get Request Info -> Time logged is not written in the database. Its been a little while, and I am struggling to get insert this variable into a custom filed (which I believe I will then have to manipulate into a string ... ) so I can then do <> for the different actions. Has anyone done this or have an example they can share? Any help would be much apricated. Thanks James
  6. +1 for me. I'd like to be able to email a supplier contact from within an incident in service manager. If I understand this correctly, at the moment I will have to create two entries for each contact contact? Thanks James
  7. Thanks for the clarification, just wanted to make sure I hadn't set something somewhere by accident
  8. Steve from support showed me the error of my ways and pointed out these could be edited/archived through the contacts section of service manager
  9. Good morning, Another day, another question . I am updating an incident via email (which works) however not all of the content of the email is being displayed. The total email length is 95 lines long, but you can only see the first 38 lines in the incident. I have copied and pasted the entire email in manually as an update and that saves/displays all of the content of the email. I have expanded out the email as much as possible. If I click the Open Post option, it opens a new tab and shows the same amount of data. The only way I can see the entire content of the email is by clicking the options button and select View Email in a new tab. Is there away to view the full content of the email within the body of the incident? Thanks
  10. @David Hall, it appears that I cannot delete them. How do we manage guest accounts? Thanks
  11. Hi @David Hall , good catch. That is exactly where they are. I did not release I had any guests in here, I shall purge them now. Thanks
  12. Hi, I am seeing some strange user account appear when I am raising incidents on behalf of other people. Without wanting to paste in live user details, I am getting this happen: I have checked the user and there are no Paul's set with no last name within Hornbill, I have checked my Azure AD settings, and the users there are correct, so I am not sure where this is coming from. Anyone got any ideas on how I fix this or is it a support question? Thanks James
  13. +1 for me too. Any news on this one please?
  14. @Victor Thanks, could be its Friday and I just can't explain what I mean - has been known to happen on occasion
  15. Hi @Victor So after some testing and scratching of head, I have realized that I posted the wrong screenshot. If I use the Wait for Request update, I do not get the execute error message, however after I have resolved the the ticket it does nothing, and I have to put an update in for it to close because of the afore mentioned Wait for Request update vs Wait for New Update. What I had actually done, is had the same logic and loop setup but had a Wait for Status Change. I must have tried the Wait for Request Update, found it not working and then tried this. I have tested and confirm that if I have the logic above, I can create an incident, apply some updates, and resolve it quiet quickly, it works the way I envisioned. However if I am slow and wait, then it generates the following error: Should I create a support ticket for this or is this as intended? Thanks James
  16. Thanks @Victor for the quick reply. I was trying this the morning this week where things went a bit crazy in Hornbill. I will re-create my BPM and do some more tests to confirm that what I did wasn't a one off and that it does actually do what I am expecting it to do. I am guessing that there is currently Wait for New Update type node?
  17. Good afternoon, On a test BPM I have created a decision loop to try and get the BPM to wait at the wait for request update stage unless the status has been changed to resolved. In my mind, after every update to an incident, it would run through the loop and see if the status was resolved, if it had it would proceed, and if it wasn't go back to waiting for an update I created a test ticket and it worked the way I was expecting, I was able to keep updating the incident and it did what I wanted, then after changing the status to resolved it progressed and completed as desired. I then tried it again and kept the ticket open for longer, proceeded to make more updates to the ticket, but not a massive amount. I then got the attached error I have read this post here: https://community.hornbill.com/topic/13117-maximum-step-count-error/ and understand that this was put in to stop infinite loops which is fine. I am just trying to understand that even if the node is a wait action, it will continue looping through in the background and not just when someone updates the ticket? I thought that I would get this error after 1000 customer/technician updates to a ticket. I know that at the time (the post is 2 years old) the recommendation was to break the loop by inserting two additional nodes on the No Match: + one node to update the request and blank out the previous resolution + another to wait for (new) resolution (if the above node is missing, this one will be bypassed because a resolution already exists) I have been asked to see if it is possible to not have it wait at the resolution stage by default. I still need a wait for resolution as there is further actions taken after the resolution is set. Thanks James
  18. Hi, I am just wondering, did this only affect instances that had been updated to the most recent patch, or would this have affected people regardless of the version they where running/not related to the patch at all? Thanks James
  19. thanks @Victor, still getting my head around where all the other bits sit in the forums.
  20. I am glad this is being looked into. As well as being able to close calls, our end users are not able to view their incidents via the portal. they can see the summary page of all of the incidents, but when they click on one incident to view the full thing they just get a blank page with the incident number - anyone else have this?
  21. Thanks @Steve Giller, I have just checked and it is currently set to ON, should I change it to off? Thanks
  22. Thanks @Steve Giller. I don't think that I am actually hitting the right PCF when I log a call on behalf of someone. Looking at app.itsm.progressiveCapture.newRequest, this calls Which runs this very basic flow -> This runs the ever-so slightly more complex I think the issue is that when using one specific Catalogue item does meet the criteria on the branch And as a result it runs the no match path. As a result, it looks like the ticket is logged using the correct PCF (because I prompt for the same things in the same order) but it isn't. As a result, when the BMP runs, it is looking for a variable from a custom form that hasn't been used and it changes the priority. By changing the order of the No Match tasks, I have confirmed that my tickets are getting logged using this path and not the correct path via the switch capture. Thanks James
  23. Thanks @Adrian Simpkins, I have followed the process/logic through from app.itsm.progressiveCapture.newRequest and it all looks correct. Strangely, almost all of my progressive captures work when used by technicians, there is only one (plus a duplicate of it for testing) that do not follow the process and get caught by my default PCF.
  24. That would be great - I currently have information here by converting what I want to say as a picture and linking that there - but it is not interactive/have links etc so this would be a +1 from us.
  25. Thanks @James Ainsworth. I have turned on app.request.raiseNew.hide so we have to select Incident to ensure this is known first and I still get the same issue. Thanks
×
×
  • Create New...