Jump to content

Search the Community

Showing results for tags 'suspend'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Hornbill Platform and Applications
    • Announcements
    • Blog Article Discussions
    • General Non-Product Discussions
    • Application Beta Program
    • Collaboration
    • Employee Portal
    • Service Manager
    • Project Manager
    • Supplier Manager
    • Customer Manager
    • Document Manager
    • Configuration Manager
    • Timesheet Manager
    • Live Chat
    • Board Manager
    • Mobile Apps
    • System Administration
    • Integration Connectors, API & Webhooks
    • Performance Analytics
    • Hornbill Switch On & Implementation Questions
  • 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 17 results

  1. Currently the 'Wait for Status Change' node only completes when the primary 'Status' changes i.e. from 'OnHold' to 'Open'. It does not trigger is the SubStatus is changed within the same parent 'Status', i.e. changes from 'Open->Pending with AM' to 'Open->Pending with Analyst'. Can the node be extended to have the option to trigger on a change to the SubStatus or can a new Suspend Node be for this. i.e. 'Wait for SubStatus Change'? Cheers Martyn
  2. Hi, I am currently working on our Problem and Known Error processes in Service Manager. As part of the Problem process, I would like the process to wait for the workaround tab to be populated before it can move on. I think I've located, under "Wait for Request Update" (Action Focus = Workaround), the way to do this however the process is just skipping this node. Is there a specific node I need to put prior to the Wait for Request Update node? I've configured various other processes with "Wait for Request Update" nodes (other action focuses, including resolution etc.) and don't recall ever having issues with those. Thanks Lauren
  3. The 'Wait for Request Off Hold' suspend node does not populate the 'Stage Expired' parameter with any value when using the 'Auto' option for the expiry period. We would expect using the 'Auto' option for the node to expire when the on hold until period expires, which it does, but the parameter is not set to indicate this. Can this parameter be set, so it is possible to use this in the workflow to determine if the hold period has expired or has come off hold following an update. We are using the expiry of the hold period to implement automatic chasing and closing of requests. Cheers Martyn
  4. The current 'Wait for Request Update', is only applicable to the first update made to the request in its lifespan. If the suspend node in is used in the BPM process after a single request update has already been made, it will not suspend. As such, support confirmed this is working as designed, so is only really useful for pausing new requests at the beginning of the workflow. Therefore this is a enhancement request to provide a new suspend option 'Wait for New Request Update', which will suspend the node at any point in the BPM and irrespective of whether there has been previous request updates and await a NEW update being made. As with the other suspend nodes, this should also include the expiry period option. Cheers Martyn
  5. Can the Suspend node such as 'Wait for Request Update' node be updated as include the application of the Working Time Calendar (WTC) to the 'Expire' period? Appreciate at the moment this will be just the default WTC, which may be different to the linked SLA WTC, but this would be a start and allow us to set the expire period taking into account working days at least. Cheers Martyn
  6. Hi all, Our Incident BPM is set to suspend for a number of reasons after logging the call. The user will log the call in the portal and then the BPM will suspend - wait for owner. Once owner is assigned it will suspend - wait for category. Now, when the BPM is suspended it will normally focus on the action it is waiting for, however on wait for category there is no auto focus. The analysts have to go into Details > Edit > Category to set the category which is a little out of the way and during our internal test phase almost all of the logged incidents have been logged without a category. There is also nothing to tell them what the BPM is waiting for so most of them didn't know they had missed anything and the ones who did know didn't know what it was. The BPM will not move on correctly without the category and tasks are not generated with is kind of the point of the BPM in the first place. Can I raise an enhancement request to make the suspend - wait for category auto focus on the required step or (preferably) present the analyst with a list of categories to select from based on the category level of the service? I don't want to add it to the procap as I don't want users picking their own categories as that is always a bad idea. Any other ideas welcomed. Thanks Dan
  7. Can I request the addition of a 'Seconds' column to the 'Expire period', as there as cases when trigger BPM actions we need to suspend for a shorter period of time than 1 minute. This is especially true when under taking integration actions and also action after other suspend nodes where the BPM process has been resumed but simultaneous operations occurring on the request have not been committed to the database which result in the BPM retrieving on incorrect data. For example we have a process which awaits the request coming off hold which is followed immediately by a get request details and decision node. We have had occurrences where the request has been taken off hold by an update on the customer portal and the BPM has resumed but the full update from the portal has not completed/committed so the subsequent decision node does not have the up to date information and branches incorrectly. Cheers Martyn Note: the above scenario was discuseed with @Victor as part of IN00158237
  8. As per of a investigation with Hornbill support (IN00158425) the Suspect - Await Expiry is applying some form of Working Time Calendar even though it does not have the WTC options the other hold/suspend processes do,. We when using the suspend node and the BPM resumes out of hours, the node will suspend not for the duration of the expiry there and then but hold until the WTC starts and then commences the timer to suspend. Cheers Martyn
  9. In our Incident process we have automatic assignemt to a team and then a "Suspend, wait for request owner" node where the analyst in charge of the "Inbox" manually assigns tickets to an analyst depending on product and availability. Is there a way to set a timer on the suspend node so that if a request has not been assigned to an owner for a set period of time, a manager is notified?
  10. Can a new Suspend - Await Feedback option be added to the Suspend Node with Expiry. Our aim is to have a post closure process which triggers after the feedback has been provided, to follow up negative feedback. If it is possible if a variable or input can be used to get the Service Feedback Expiry period set in the service definition. Cheers Martyn
  11. elated to my post regarding 'Suspend and Wait Feedback' (link at the bottom of this post), can all the Suspend Node be updated to allow the insertion of separate variables into the Expire Period values for Years, Month, Days, Hours and Mins. This will provide flexibility to set different Expiry periods without having to hard code in the BPM with multiple decision nodes. Cheers Martyn
  12. 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
  13. Afternoon, As part of a process i'm building we suspend a ticket, wait for request email: However once the email has been received into the ticket, the process is not starting up again, it should the move the ticket to open. However that is not happening? Am i assuming the node does something it doesn't or is there a issue? If this isn't the node to use to start the process up again could someone please point me in the right direction? Many thanks Hayley
  14. Are there any thoughts about having Wait for Attachment in a suspend node there is the option to change the focus but not to wait? Also, we would like a BPM task to indicate if there is an attachment in the request and to pull the description/filename into the task, but can't currently find a way of doing this.
  15. Good morning, I have been asked to investigate if there is a way to stop accounts from suspending, when users put there password in wrong? Many thanks Hayley.
  16. It would be useful to be able to mark a service subscription as for an customer organisation (or other subscription containers) as suspended or archived to stop the customer from logging new requests if their maintenance has expired (suspended) or removed form their service list when they have stopped using that service. The latter we can of course achieve by deleting subscription, but the former would be useful. Cheers Martyn
  17. We are attempting to implement a process where the analyst will put the incident on hold after carrying out their initial investigation task and either requesting the customer to provide more information or test to see if the issue is resolved. Therefore we want the process to suspend awaiting for change in status, i.e. status <> hold, so then a decision node can be used to determine the next task to be created depending on status it has been changed too. At the moment there is no suspend node to pause the task awaiting the status to change from its current value, therefore could this be raised as Request for Change. Thanks. Martyn
  • Create New...