Jump to content

Bob Dickinson

Hornbill Product Specialists
  • Content count

  • Joined

  • Last visited

  • Days Won


Bob Dickinson last won the day on August 30

Bob Dickinson had the most liked content!

Community Reputation

52 Excellent

About Bob Dickinson

  • Rank
    Product Specialist
  • Birthday 08/26/1982

Profile Information

  • Gender
  • Location

Recent Profile Visitors

1,031 profile views
  1. Field for ticket 'Assigned to'

    Hi @Joyce We have a table called h_itsm_request_team_assignment which records an entry every time a ticket is: a) Assigned to a new team b ) Assigned an owner or new owner From this you should be able to work out which requests have been assigned multiple times. If you need any assistance, please let me know the type of Report/Chart you are looking to create, any criteria (e.g. Type of request? Assigned between teams or assigned between owners?) and over what time period Kind Regards Bob
  2. Extra Details Issue

    Hi @SJEaton Sorry I'm a bit late to the discussion but I just wanted to contribute, and potentially take a step back. Firstly - I would advise to ALSO configure any custom fields from Service and not directly from a request. Doing it from a request simply makes thing more confusing, and you have more control when using the "View Details" for on the Service. If we were to create a brand new Service, as mentioned above, we have the option to use up to 17 custom fields (Custom A to Custom Q). This is also per Request Type - so you can have 17 custom fields for Incidents against your Service, and 17 for Service Requests against your Service. In my screenshot below, I've configured them all in the view details form: I've also made all of this visible even if no value exists. And as you can see, when I raise an Incident, this is what I see: You can have multiple Catalog Items with Progressive Captures against a Service - and as you have done, you can map the responses to the catalog items. But regardless of how many you Catalog Items/Progressive Captures you have, you still only have the 17 Custom Fields against that Service to play with. So for Example - in my Service "Bobs Service 10" I have two catalog items: For my "New Starter" Catalog Item, I have created a Progressive Capture and have 16 questions, all about the new starter e.g. "What is the Starter Name?" "What is the Starter Date?" "What is the Starter Manager?" . . "What is the Starter Email?" In theory I can use 16 of my custom fields against that Service, each with a unique label, to map all the answers to - if I need to. So: "Starter Name" --> (Maps to h_custom_a "Starter Name") "Starter Date" --> (Maps to h_custom_b "Starter Date") "Starter Manager" --> (Maps to h_custom_c "Starter Manager") . . "Starter Email" --> (Maps to h_custom_p "Starter Email") Now I come to my Leaver Catalog Item and Progressive Capture. Because this falls under the SAME service, if I want to map to any custom fields with a unique label, I only have 1 left - h_custom_q. If I have understood correctly, you are in a scenario where you have multiple customer questions in a number of Progressive Captures and you are trying to capture them on the request details. The bad news is, that as per above you are limited to the 17 per service. So how do you resolve this? You have a few options: 1) Split out the Service - In my example above, if I really need to capture those questions in the request details, I would create a new service that is specific to a New Starter. Each Service gives you 17 Custom Fields per type. 2) Consider why you need the Answers as Custom Attributes - All Progressive Capture answers are captured within the questions section anyway. The main reason that people want to map answers to Custom Fields is so that they can be edited in the future (e.g. a Change Implementation Plan). But if the data is unlikely to change, (e.g. the Name of a New Starter) do you really require that answer to be mapped? 3) User Shared Labels - A bit more tricky and will involve some careful consideration - but are there any custom attributes that can be shared across you Catalog Items? In my example above, perhaps instead of "Starter Name" and "Leave Name" as the label for h_custom_a, I would just have "Name" so it can be shared. Apologies if this is going over old ground or I have misunderstood any of the original issue that you posted - I also appreciate this is a bit harder to do when you have already set up your Service Catalog in a particular way as you need to rework it rather than begin at the Service/Custom Fields level as I have done above. But please let me know if you have a specific issue or problem to overcome and perhaps we can assist a more granular capacity. Kind Regards Bob
  3. % Incidents / Request closed with SLA by team

    Hi @Prathmesh Patel It might be useful to understand what you would like the actual output to look like first, as that can help drive the type of measure and widget to use - sometimes just by drawing it out. Its also important to understand the timeframe you would like displayed. Is this the kind of thing you are after (I've just created this quickly in paint brush to understand)? Notice that I am just showing Last Months samples so this is the type of thing its useful to think about and specify - and what it may look like it you combine multiple samples on a chart Kind regards Bob
  4. Business Process report

    Hi @chrisnutt The link between a request and the stage/checkpoint, IS currently stored in the DB but its stored in a way that is designed towards efficiency - using XML and long "State" strings rather than individual components in columns and records - basically making it very difficult to report upon. My personal suggestion in this scenario is to create a Change Board - I know you mentioned that not everyone has visibility of it, but its still a useful resource anyway for those who are Hornbill users. Set up your Change Business Process to automatically move the request between specific lists you create within your board - like the examples you have mentioned "With CAB " and "Work In Progress". Once you have set up this board and its working - you can actually report on the board itself - for example, "How many requests do we have in the "Work In Progress" state. You could perform a join between the h_itsm_board_cards table and the h_itsm_requests table to get all the information required in your report if you wanted to create it using our reporting functionality to export to HTML CSV and distribute to the third party. I hope this makes sense - in summary, report on your Change Board rather than report directly on the request stages. If you can create the board and it works, feel free to post back here and I can provide some assistance in setting up the report if you require. Kind Regards Bob
  5. Mean Time between Major Incidents

    Hi @chrisnutt Ok thanks for the explanation. This is a very complex query to formulate so unless you know a little SQL is a difficult one to quickly establish. Its just taken me quite some time, but I THINK I have managed to get something that may be suitable for you. Firstly this is performed in Advanced Analytics - and you will be creating a "List of Counters" Widget: The following screenshot shows the finished article, but to get to this when you create it, you need to add some text and an icon, and then click the edit button: This gives you the screen to enter the data for the widget. Try and enter the following based on the appropriate locations in the screenshot below 1 - Avg 2 - (TIMESTAMPDIFF(second,h_datelogged,NextDate)) 3 - (SELECT h_pk_reference, h_ownerid, h_datelogged, (SELECT Min(h_datelogged) FROM h_itsm_requests T2 WHERE T2.h_datelogged > T1.h_datelogged AND h_fk_priorityname= 'Immediate' AND h_requesttype = 'Incident' ) AS NextDate FROM h_itsm_requests T1 WHERE h_fk_priorityname= 'Immediate' AND h_requesttype = 'Incident' ) AS AllDays The text: h_fk_priorityname= 'Immediate' and h_requesttype = 'Incident' which is mentioned twice in number 3 above, is specific criteria for your organisation relating to the tickets you want to compare the dates between - above you mentioned this is all incidents of a particular priority (Immediate) so I have included that in the example...but you may want to add to/amend these criteria I hope this helps. Let me know if you run into any difficulties (I ran into plenty during the investigation of this! Kind Regards Bob
  6. Mean Time between Major Incidents

    Hi @chrisnutt Just to clarify, when referring to the (mean) time, are you looking for the duration of time a request was open between it being logged and now? And would this just be for currently open incidents or for requests that have been resolved (in which case the time may be between the log date/time and resolution date/time)? Kind Regards Bob
  7. Daily run widget with current month total

    Good point @Joyce In which case, you should probably investigate why some of your Resolved or Closed Requests have a NULL value in the h_withinfix column, as if they have an SLA associated, I would expect this to be showing 0 or 1 Kind Regards Bob
  8. Daily run widget with current month total

    Hi @Joyce The reason you are finding the difference in the stats is because of how SQL works out an average - and the fact that it does not account for null values in an average calculation. In your query, because you are looking at the calls to date (i.e. in August), there is very likely to be requests that are ongoing - they have not met or breached any SLA yet - so Hornbill does not put a 1 or a 0 in the column for these, its simply empty. This means that you actually have 3 different potential occurrences - 1, 0 or NULL. Now lets take an example: Reference h_withinfix IN00000001 1 IN00000002 0 IN00000003 NULL (this is an ongoing request that has not yet met or breached SLA) IN00000004 1 You might expect that if you were doing an average for the number of met (h_withinfix=1) requests it would end up at 50%: Met Requests (2) divided by Total Sample (4) = 0.5 What ACTUALLY happens is that it does not include NULL values in the total sample - so the average would return 66.66%: Met Requests (2) divided by Total Sample (3) = 0.6666 This is what I believe is happening for you - its rightly ignoring the NULL values, giving you a higher percentage than what you are expecting. There is a way around this - if you would like NULL values to count as 0 (not breached) we can perform this substitution for the sake of the calculation using the COALESCE function as per the screenshot below. Using my example above, this would return the average as 50%. (This function does NOT replace the values in the database from NULL to 0 - its purely used as part of the average calculation). Give this a try on the AVERAGE widget you have referenced above and see of this gives you a figure that you were expecting. Kind Regards Bob
  9. Priorities and New Service Levels in Portals

    Hi @Martyn Houghton At present, this has still not made our 90 day schedule, but I will have a look at the request to see when this was last reviewed. Kind Regards Bob
  10. Tickets resolved per team

    Hi @Dan Munns In terms of last months requests, try this: (h_requesttype = 'Service Request' OR h_requesttype = 'Incident') AND (h_dateresolved >= LAST_DAY(NOW() - INTERVAL 2 MONTH) + INTERVAL 1 DAY) AND (h_dateresolved < LAST_DAY(NOW() - INTERVAL 1 MONTH)) AND (h_resolvedby_teamname = 'IT Service Desk) Does this work for you? Kind Regards Bob
  11. Function for yesterday's date

    Hi @Joyce The average is slightly different as its a mathematical function based on the values that are returned from the column specified, divided by the count. E.g lets take your query above - if you did the average h_withinfix, and there where 600 results - it would add the h_withinfix values together of all of them, and divide by 600. Because the h_withinfix contains a 1 or a 0, and you have already filtered where h_withinfix = 1, the results would be: 1 + 1 + 1 + 1 (etc 600 samples) = 600 Divided by 600 = 1 (Thats the average value) So as you can see it doesn't really give us any decent information The average wouldn't work if you entered h_pk_reference as they arn't integers (i.e. you can't have SR0000182 + IN00000827 + IN00000987 etc) Where this works better is when you have a number that is variable per incident. For example, number of times request reopened. If you had 600 samples, the calculation would be something like: 0 + 0 + 1 + 2 + 0 + 1+ 0 + 0 + 0 + 0 + 0 ( etc 600 samples) = 44 Divided by 600 = 0.07 Average number of reopened calls Kind Regards Bob
  12. Function for yesterday's date

    Hi @Joyce Both need a little bit of amendment: 1) In your SQL Widget, you need to change the h_withinfix at the top next to COUNT, to h_pk_reference 2) Also in your SQL Widget, you need to now add in the h_withinfix to the WHERE statement so simply add: AND h_withinfix = 1 This should provide hopefully the true count In your measure: 3) Your title states measuring a percentage here, but you are actually measuring a count, so you may want to amend this 4) As above, you need to add the h_withinfix to the WHERE statement so simply add: AND h_withinfix = 1 Now if you resample, do the values match? Kind Regards Bob
  13. Resolution Emails

    Hi @Dan Munns We don't currently have any automated option outside of BPM that would be able to send an email automatically on a request resolution. However there are a few ways to help prevent the BPM being bypassed and requests being resolved too early: Prevent Resolution with an open activity - If you use activities in your business process, you can turn on the Service Manager Application Setting: webapp.view.ITSM.serviceDesk.requests.resolve.denyWithOpenActivities - this will ensure any open tasks must be completed before a request can be resolved Prevent Resolution until a closure category has been added - Similar to above, if you use closure categories, you can use the Application Setting: servicemanager.request.closureCategory.default.required which will ensure this category must be added before the resolution button will work Lock the Resolution Action until required - You can prevent the resolution tab from being active to be selected until the stage in your process when it should be available by using the Access Control functionality. We have a video about how this works here: https://www.hornbill.com/blogpost/lock-and-unlock-request-actions/ I hope this helps, Kind Regards Bob
  14. Request for clarity on Configuration Manager

    Hi @samwoo Hornbills Configuration Manager App has now been published as a Free App as we are looking to solicit feedback on what features and functionality you, our customers feel are required to take this to the next stage in its evolution.We will continue to mature the functionality over time and at some point in the future we may choose to make this a chargeable App. In event that we do introduce charging, as someone who is actively using the App and providing feedback you will be able under our Priced for Life policy continue to use the App for Free and, all new subscribers from that point will then require a paid for subscription to make use of the Hornbill. Configuration Manager App. In simple terms, you are free to add as many assets into policy as you require and will not be charged! Kind Regards Bob
  15. Function for yesterday's date

    Hi @Joyce To help me investigate this, could you please take and post a screenshot of the criteria you are using for each for me to compare? Kind Regards Bob