Jump to content

Foley Coker

Hornbill Users
  • Posts

    48
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Foley Coker's Achievements

Enthusiast

Enthusiast (6/14)

  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

1

Reputation

  1. hi @James Ainsworth - i've worked with martin on this, and this is the part of the workflow in question. if multiple suspend nodes cannot be used in parallel, is there a way to be able to keep the master ticket from closing, until the splintered tickets, be it 1, 3, or 5 different linked requests are completed or some sort of indication of completion such as a timeline update? we currently want the one ticket logged by the customer to not immediately close, but also need it to splinter into various teams based on their choice within the intelligence capture, and those linked requests may meet completion at different times due to being sent to different teams.
  2. hi @Steve Giller this has worked for us. thank you
  3. Hi, there is a report i have created that fails every time to send to the intended users. I am presented with the below message, but i have automated reports that work for me. do the intended recipients need any specific roles in order to receive reports via email, as i cant see any difference between this and other ones made.
  4. hi all, this seems to have since been resolved, and ive been able to access the site.
  5. Hi all, is there a current issue with the success site https://success.hornbill.com/hornbill/ has been giving me a blank screen all day and i am unable to report a current issue.
  6. @Ehsan will this update be widely released to all clients? and will this resolve those for already raised tickets, or just newly raised tickets after the patch? as we have been experiencing the issue also and the workaround is not suitable for all instances where the date visibility is necessary. Thanks, Foley
  7. @Victor - would it be possible to be added into this, our data protection team who utilise the platform have some questions.
  8. @Dan Munns hey Dan, thank you for the response. It was clear to me haha, Unfortunately we had tried that as one of the solutions as well, and that for some reason was still picking up the previously selected authoriser, rather than giving the user the authorisation key to select a new one. I felt it may have had something to do with a get request info, possibly referencing previously stored data on who the authoriser was but im not entirely sure.
  9. @Dan Munns Hello Dan, i am revisiting this post as i have come to bit of a standstill regarding the re-authorisation. In the below screen shot, we are attempting to place an expiry on the authorization node, and when reached it goes back to the request owner to select a new authorize. However when we initially tagged it to the first suspend await authorize, it would not provide the authorization key again but just set the authorization to the previously selected authorizer. We then built it as below with a different suspend node to then feed back into the auto assign authorization but yet it is still picking up the originally selected authorizer. Please can you advice how we can achieve this as the wiki did not provide much clarification. Thanks
  10. Agreed, this is something that our organisation could really use, as the bottle neck in pushing the approvals, for short notice leave, or long term leave is causing hold ups.
  11. Hello All, We currently have a number of processes utilizing the automation for authorization, with the data query in the procap set to co-workers alone, and then using the raw value for the authorization node to send an email to the selected person. This in theory would work well as our cost center managers would all have a collaboration license for this purpose. Although there is the ability to use external authorization with an email input, this extra level of protection was deemed more suitable. However, in practice, it appears that the data query in the procap even if set at co-workers is allowing the customer to select basic users. The selection works when a actual user with the license is selected, but it should not present the basic users. This in turn causes the request to fail every time it reaches the authorization node as there is no collaboration license for the basic user. is this a known error, or is there something else we can do to ensure they are only able to select the collaboration licensed users through that data query? Thank you, Foley
  12. Thank you @Steven Boardman Look forward to the update!
  13. Hello All, we are currently utilizing the time sheet application and the wiki shows information that appears to possibly not fully be relevant any longer / or ahead of its time. This is in relation to categories. We can only view one role which is TimesheetManager User. This role gives not only the use of time sheets, but also all the other relevent features of admin like creating/deleting etc.. Unfortunatley for staff to use time sheets they also require this role, which creates the fear of unwarranted edits/additions and a lack of protection for other members if viewable by all. The wiki says there are time sheet Timesheet Category Manager & Timesheet Administrator which would add different levels to the roles, but this is not available on our platform.
×
×
  • Create New...