Jump to content

Search the Community

Showing results for tags 'wait for request update'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Hornbill Platform and Applications
    • OpenForWork
    • Announcements
    • Blog Article Discussions
    • General Non-Product Discussions
    • Application Beta Program
    • Collaboration
    • Employee Portal
    • Service Manager
    • IT Operations Management
    • Project Manager
    • Supplier Manager
    • Customer Manager
    • Document Manager
    • Timesheet Manager
    • Live Chat
    • Board Manager
    • Mobile Apps
    • System Administration
    • Integration Connectors, API & Webhooks
    • Performance Analytics
    • Hornbill Switch On & Implementation Questions
    • GRC Manager
  • About the Forum
    • Announcements
    • Suggestions and Feedback
    • Problems and Questions
  • Gamers Club's Games
  • Gamers Club's LFT

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start








Website URL





Found 3 results

  1. 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
  2. Evening all, almost Friday! New Hornbill Service Manager customer here. I'm currently trying to get my BPM workflow to move past a "Wait on Request Update" suspend node by updating it using PowerShell and the API but I'm hitting an issue and was hoping someone could steer me in the right direction. Up to now I've been able to update the requests using Requests::update to make a number of changes but this doesn't appear to progress the flow past the suspend node. I've also attempted updating the description field via the API while using the "Wait for Request Description" task in the flow but this too didn't go anywhere. This is the code I'm using to do the update to the description field in this case. # Build XMLMC API call Add-Param "requestId" "SR00000646" Add-Param "h_description" "Updated AGAIN!" $xmlmcOutput = Invoke-XMLMC "apps/com.hornbill.servicemanager/Requests" "update" -Verbose Is there a different method I should be using to fulfil the update action that the suspend node is waiting on? Many thanks Brendan
  3. In order to try an get a workaround to the issue with the 'Wait for Status Change' node not triggering when the SubStatus is changed (post link at the bottom of this one) I am attempting to use the 'Wait for Request Update' node. My logic was that I could use the 'Wait for Request Update' node to suspend the workflow and then check if the SubStatus had changed. If not return to the suspend node and wait for the next request update. Extract of the workflow and condition statement below. However my BPM do not un-suspend when making a change to sub status, which leads me on to my question of what does trigger the 'Wait for Request Update' suspend node to complete? Cheers Martyn
  • Create New...