Jump to content

Search the Community

Showing results for tags 'service level'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Hornbill Platform and Applications
    • Announcements
    • Blog Article Discussions
    • General Non-Product Discussions
    • Application Beta Program
    • Collaboration
    • 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

    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 19 results

  1. At the moment the Update Request Service Level option (screen shot below) only allow you to re-trigger the setting of the Service Level base on the rules. Can we new option be provided to allow the same functionality that is in the User App where the Service Level Agreement and Level can be changed. If this option can include the injection of variables as well as hard coded values. https://wiki.hornbill.com/index.php/Service_Manager_Business_Process_Workflow Cheers Martyn Martyn
  2. Hi, We have noted an Incident Request that has reported as Resolution SLA Breached by an Escalation Event, despite the Resolution SLA not actually breaching. Is there anyone in Hornbill Support that can look into this for us please. I have checked as much as I know about (and I set all this up) so at a loss why the Escalation Events have triggered. Not seeing this anomaly on other Incident tickets. Happy to share the details 'offline' to someone. Thanks, Steve.
  3. Related to the display of the new Service Levels in the Request List, there also needs to be the ability to display currently assigned Service Level on the portal request list and the request itself when opened. Similarly for those still using the original priority SLA implementation this should also be visible. As people apply there SLA differently it would be best that this was configurable in some ways, as for example for service we have moved to the Service Level Management method the priority is only used initially to set Service Level based on the rules. When the Service Level is changed the priority value is out of date and is no longer applicable, so for these services we would only want to show the Service Level not the priority. Cheers Martyn
  4. Can I request an enhancement to add a new BPM Automatic Task node to check and output a result which can then be used in a subsequent decision node, to indicate if the the current date and time is within or outside of the Working Time Calendar associated with the Service Level Agreement associated to the current request. The reason for this is so that we can trigger alternative actions if the request is logged out side of working time on the portal, but is of sufficient priority to need to additional notification actions to personnel on call. Though we can achieve this partially by auto assignment and picking up when no analyst are online etc, this is not foolproof and it would be better to do this base don the working time calendar rather then relying on analyst to rember to logout/set their availability manually. Cheers Martyn
  5. Can the current Hornbill Request Import V1.2.0 be updated to include the following additional capabilities. Support the import and matching of Sub Status, only current supports parent status. Support the import and matching of Service Level Agreement and Service Level's. Extend current supported request types, Incident & Service Request, to include all other types, i.e. Change, Problem, Known Error and Release. Also as per the SQL Contact Import also support MySQL v8 connection with the new authentication method. Cheers Martyn
  6. Following on from the recent colour coding of priorities, see post below, can the same capability by added to the Service Level Management - Service Level's, as we the latter for managing our requests rather than the original priorities. This would apply in both the Request List and Request View. The idea being that in the for each Service Level within a SLA you can assign a colour as you can in with the original priorities. Also has many of us have more than three Service Levels within our SLA's can we the number of colours be extended to at least 6 for both implementations? Cheers Martyn
  7. Hi all, We have recently created a number of new Service Levels for 2019. We would now like to either delete or at least hide the old ones so they can no longer be used but we don't want all of our historic tickets to be left without a Service Level. Is there a way to do this?
  8. Hi everyone!

    Happy New Year!

    As you probably noticed I was away from forums for the past month as I took some time off. I am back(ish) now  (because I am caught up in some other work as well so I might not be able to be on forums as much for now) and slowly catching up on all activity (including all notifications and PMs). I will get back to each of them eventually however it might take a bit longer until I will be able to get to yours. As usual, if you are subscribed to a success plan you can always raise a request with support to expedite a forum discussion/answer.

    Cheers!

  9. @Steve G With reference to the "Request Import Utility", I can see there is a mapping for Priorities, but how do we map Service Levels and also populate/set timers? Cheers Martyn
  10. Hi, Quick question: is it possible to hard code a contact when a certain condition is met with service levels? At the moment, it seems we can only pick the request's owner or its manager. In our case, this is a major problem for response SLA because the request rarely assigned to a person when it breaches (or is about to). Any ideas? Can I hard code the name in the database directly? Thanks, Lyonel
  11. Can the Requests - Log Request node be extended to include the options to copy over the following additional characteristics Connections Attachments Service Level Catalog Cheers Martyn
  12. When configuring SLA response and resolution targets and expiry times on certain BP nodes you might find the target being set differently than possibly expected. This is because a common oversight as these timers needs to be expressed in SLC (Service Level Calendar) times or working hours or business hours (which are usually X hours/day) rather than calendar time (which is 24 hrs/day). When configuring a target time of N days, the value needed to be set would be N working days rather than N calendar days. The value that needs to be set will be obtained by multiplying N with the number of working or business hours/day. We advise to always configure hours (rather than days) as it is easier to figure out the values required to be configured for SLA targets or expiry times on business process nodes. However, in certain areas (e.g. SLA timers), depending on the target, it might not be always possible to use hours exclusively. Below is a quick example of how to find out which values needs to be configured depending on the intended target: Let's say we need to configure a resolution time (or an expiry time) of 5 days. We need the target to be set in 5 days from now. Let's also say the working hours are 7.5 hours/day although this really depends on your SLC. Step 1 is to find out the number of working hours equal to the 5 days we need to set: 5 days * 7.5 hrs/day = 37.5 hours. You need to configure round values therefore if you don't have a round number of hours you also need minutes (seconds, etc.). The 37.5 hours equates to 37 hrs and 30 min. In conclusion, for a 5 day target, the configuration needs to be 37 hrs and 30 min. As mentioned above, for simplicity always use hours if possible. If you need to configure this value as days/hours/min then the 37.5 hours need to be divided by 24 (which is the number of calendar hours in a day) resulting in 37.5 / 24 = 1.56 days. The 1.56 days equates to 1 day and 13.50 hours. This further equates to 1 day 13 hours and 30 min. In conclusion: 5 day target in the context of 7.5 working hours/day is set as: 37 hours and 30 minutes or 1 day 13 hours and 30 min If you don't want to be bothered with the mathematical calculation, you can use this Excel sheet to find out what values you need to configure. Type in the desired target time and the number of working hours per day. The values you need to configure are in red: Hornbill_Timer_Targets.xlsx IMPORTANT: the above does not apply when configuring expiry times on human tasks. Human tasks do not account for Working Time Calendar and as such the above setup does not apply in this scenario.
  13. I understand using days, hours and minuets when configuring a service level target, however having them displayed in such units often confuses users (including me sometimes) when selecting or changing a service level on a incident. Would it be possible to have the option to set the display units so it is more understandable to the user, i.e. being able to specify displaying it as Minutes, Hours, days? Also perhaps having a link of at least display of the working time calendar name linked to the Service Level. Cheers Martyn
  14. Whilst checking on some anomalies in our SLA reports, where 'Within Fix' and 'Within Response Time' are reporting as 'Not Set', we have discovered it is possible to amend the Service Level on a request by selecting only the from 'Available Service Level Agreements'. Only have to select from the 'Available Service Level Agreements' and complete the mandatory 'Reason' field. 'Service Level' is not mandatory. Surely this should be mandatory? Cheers Martyn
  15. The 'Get Request Information' BPM node appears to be missing the fields for 'Service Level Agreement' and 'Service Level'. We are in the process of going live with SLM and a number of our activities currently insert the flowcode value of Priority, which we are attempting to change to Service Level. I tried refreshing the nodes and also get Service Details, but that still does not provide the SLA or Service Level values as usable variables. Is there a different node I should be using? Cheers Martyn
  16. When viewing requests on the Mobile app there appear to be some key fields which are not present, such as details of the Customer, Priority, Service Level, Sub-Status etc. Are there any plans to improve the Service Manager element of the mobile apps to add this level of detail in? Cheers Martyn
  17. We are in the process of implementing the new Service Level's to replace the original priority levels. We have roles based on the system Full and normal Incident Management Users, but need to understand what permissions are required to allow a user to change the service level on a request. At the moment the users are not able to click and edit the service level on the requests setup with the new service levels. Cheers Martyn
  18. Hi guys, I don't know if ti is a known issue or if you are aware of this but I am having troubles with my reporting regarding SLAs and performances. Indeed, the fields h_responsetime and h_fixtime in the requests table do not seem to match what I can see on screen. For example, here is my request: And what I have in the database for that same request: As you can see, none of the values match what is on screen... One common denominator in pretty all of the similar cases is that the priority and the SLA was changed at some point during the life of the requests. Any idea on: Is it an issue? Are you aware of it? Where does the screen gets its data from? Which table should I query to get the correct data for my report? Thanks in advance for your help.
  19. Hi all, I have made a few changes to our organisation structure and have been through and made sure all the team refs are pointing at the newly created and correct teams. I have not run any of our BPMs since the introduction of the Corporate Service Level Agreements but I am now getting errors when the timer is started. The error is as below: Line Timestamp Severity Group TID Description 31448 20/01/2017 11:13 error scripts 14932 nodeName: Invoke Flowcode: smSLMGetServiceLevelAgreement; nodeId: d80806a7-b7bb-4399-9c1d-8aea35df601d; "EspMethodCall:invoke: Operation[apps\/com.hornbill.servicemanager\/Requests:smSLMGetServiceLevelAgreement] FlowCode Exception (com.hornbill.servicemanager\/entities\/Requests\/fc_ops\/smSLMGetServiceLevelAgreement): FlowCode failed to return required output parameter: serviceLevelAgreementId" 31447 20/01/2017 11:13 error comms 14932 Operation[apps/com.hornbill.servicemanager/Requests:smSLMGetServiceLevelAgreement] FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_ops/smSLMGetServiceLevelAgreement): FlowCode failed to return required output parameter: serviceLevelAgreementId 31446 20/01/2017 11:13 error comms 14932 Operation[apps/com.hornbill.servicemanager/Requests:smSLMGetServiceLevelAgreement] FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_ops/smSLMGetServiceLevelAgreement): FlowCode failed to return required output parameter: serviceLevelAgreementId 31075 20/01/2017 11:13 error scripts 14932 nodeName: Invoke Flowcode: smSLMGetServiceLevelAgreement; nodeId: d80806a7-b7bb-4399-9c1d-8aea35df601d; "EspMethodCall:invoke: Operation[apps\/com.hornbill.servicemanager\/Requests:smSLMGetServiceLevelAgreement] FlowCode Exception (com.hornbill.servicemanager\/entities\/Requests\/fc_ops\/smSLMGetServiceLevelAgreement): FlowCode failed to return required output parameter: serviceLevelAgreementId" 31074 20/01/2017 11:13 error comms 14932 Operation[apps/com.hornbill.servicemanager/Requests:smSLMGetServiceLevelAgreement] FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_ops/smSLMGetServiceLevelAgreement): FlowCode failed to return required output parameter: serviceLevelAgreementId 31073 20/01/2017 11:13 error comms 14932 Operation[apps/com.hornbill.servicemanager/Requests:smSLMGetServiceLevelAgreement] FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_ops/smSLMGetServiceLevelAgreement): FlowCode failed to return required output parameter: serviceLevelAgreementId 30897 20/01/2017 11:13 error scripts 14932 nodeName: API Call: Resume BPM Process; nodeId: 39535400-73fd-4464-80d7-bec0dc811f07; "EspMethodCall:invoke: Operation[bpm:processResume] The specified bpmProcess cannot be resumed: The process is currently busy" 30896 20/01/2017 11:13 error comms 14932 Operation[bpm:processResume] The specified bpmProcess cannot be resumed: The process is currently busy 30895 20/01/2017 11:13 error comms 14932 Operation[bpm:processResume] The specified bpmProcess cannot be resumed: The process is currently busy 30894 20/01/2017 11:13 error perf 14932 bpm:processResume() Operation Invocation results: failure (199958528 B, 13 ms, 0 kB, 1 ms, 0 kB) 30421 20/01/2017 11:13 error scripts 14932 nodeName: Resume BPM Process; nodeId: f107f874-7ca7-46c2-b9dd-e564153cdb71; "EspMethodCall:invoke: Operation[bpm:processResume] The specified bpmProcess cannot be resumed: The process is currently busy" 30420 20/01/2017 11:13 error comms 14932 Operation[bpm:processResume] The specified bpmProcess cannot be resumed: The process is currently busy 30419 20/01/2017 11:13 error comms 14932 Operation[bpm:processResume] The specified bpmProcess cannot be resumed: The process is currently busy 30418 20/01/2017 11:13 error perf 14932 bpm:processResume() Operation Invocation results: failure (195932160 B, 10 ms, -28 kB, 0 ms, 0 kb
×
×
  • Create New...