Jump to content

Search the Community

Showing results for tags 'onhold'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • 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
  • 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

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Organisation


Location


Interests


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype

Found 6 results

  1. As discussed on the Supplier Manager Webinar, it is possible to trigger the start and stop of a Event linked to a Supplier, from the workflow in Service Manager, there will be occasions when within a single event the timer being run against the supplier will need to be paused. Starting and Stopping multiple events for a single 'service incident' would not give a true reflection of the service level being provided. For example, depending on the service involved there may be a period of time the responsibility returns to us the consumer of the service where the time would not run. i.e. arrange remote access, scheduling engineer visit/downtime, dispatching unit to the supplier etc Therefore can I raise an enhancement request to add the ability to 'Pause' and 'OnHold Until' the Supplier Event Timer in the BPM. Cheers Martyn
  2. We have an intermittent issue where all our escalation actions are trigger at once when a request has been on hold for significant period of time. This appear to be being triggered by the Escalation Actions conditions being evaluated before the requests response and resolution target dates are updated to take into account the on hold period. In our case we have escalation actions set at percentage of remaining resolution time as below, which we calculate and add into the appropriate service level as the appropriate durations. 80% 60% 40% 20% 10% 5% 1% Therefore when a request come of hold and the timers is restarted, you should only trigger the appropriate next action as the timer runs. However what we get is all the escalation actions triggering at ounce as the Resolution Target value being used in the evaluation is the value when it was put on hold, not the new recalculated value when the request comes off-hold. In the example above the request was taken from on-hold to open by a email applied from the shared mailbox, which then resulted in multiple escalation actions being triggered. Cheers Martyn
  3. At the moment you are not able to use the Email option when a request is on hold, but you are able to use the update option. Is this a configurable option, as there are quite often the requirement to generate an email from the request when it is on hold, even if it is to chase up the customer. In SupportWorks you can undertake a Call Update actions and email when the incident is any status other than closed. Cheers Martyn
  4. @Steve G I am having an issue the Hornbill Request Importer when importing request as status.onhold. From the error I can see that it is needed an 'onHold until datetime', but there is not a field in the import config for this. If my memory servers me right from Support Works days it used the resolved/closed date. Do I just supply the 'onHold until datetime' in the h_dateclosed for those records which are on hold? 2019/03/07 15:55:37 [DEBUG] Service Cached [Open Objects Historic Incidents] [550] 2019/03/07 15:55:37 [DEBUG] Priority Cached [3]: Low 2019/03/07 15:55:37 [DEBUG] New Service Manager Request: IDXIN00086339 2019/03/07 15:55:37 [DEBUG] Activity Stream Creation Successful 2019/03/07 15:55:37 [DEBUG] Request Log Date Update Successful 2019/03/07 15:55:37 [ERROR] MethodResult not OK: Unable to place request on hold [IDXIN00086339] : FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_ops/holdRequest): Input parameter validation error: The dateTime value '' specified is invalid or out of range for element <onHoldUntil> at location '/methodCall/params/onHoldUntil' 2019/03/07 15:55:37 [DEBUG] <params><requestId>IDXIN00086339</requestId><onHoldUntil></onHoldUntil><strReason>Request imported in an On Hold status. See Historical Request Updates for further information.</strReason></params> 2019/03/07 15:55:37 [DEBUG] Retrieving Historic Updates for 2019/03/07 15:55:37 [DEBUG] SELECT * FROM oohistoricupdates WHERE callref = 52526 Cheers Martyn
  5. 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
  6. There only appears to be BPM nodes to start and stop the Response/Resolution timers. Is there anyway to put the incident OnHold or Pause the timers as an automated task rather than having to put a Human Task, instructing the owner to do it manually? Cheers Martyn
×
×
  • Create New...