Steven Boardman

Hi @Keith The measures are currently based on a single table, and this is certainly the case for adding Saved Data Columns for future data manipulation in widgets. There are options in the Query Where Clause to be able to use a sort of nested query, for example: h_pk_reference IN( SELECT h_request_id FROM h_sm_requests_extended WHERE h_custom_2 = 'Live' ) AND h_requesttype = 'Problem' So this would allow me to only include requests where the h_custom_2 value in the h_sm_requests_extended = Live and the requests are type Problem in the count, obviously we can extend this to evaluate more of the custom field values, but as i say it is not currently possible to include columns from more than one table in the Saved Data Columns for future use. Would you be able to give us some examples of the output you are looking to achieve? Thanks Steve

Hi @Prathmesh Patel Time management on the Hornbill platform can be managed through our timesheet app. Once installed alongside Service Manager, you can selectively choose where you want the option to record time on requests - for example just against the Resolution action, or against say the general update, email or other action options. On the Service Manager wiki page there is information on the Timesheet manager pluggin for Service Manager: https://wiki.hornbill.com/index.php/Service_Manager This will cover configuring and using the timesheet pluggin which will allow you to add the time capture to the Resolution action as below: More info on the additional benefits of Timesheet Manager are detailed here: https://wiki.hornbill.com/index.php/Timesheet_Manager We also have a small planned development to add an optional time capture field to the resolution action instead of using Timesheet Manager app, but this is not scheduled, once this is available as an alternative option i will update this post. Hope this helps Steve

Hi @DougA There is a system setting that you can enable which will limit the displayed services to only those which the customer is subscribed too, and those services which the analysts (logging the requests) teams support. servicemanager.progressiveCapture.servicedetails.enableSupportVisibility - The default setting for this is 'Off' - When the setting is 'On' the Services displayed on the Progressive Capture Service's form will be filtered to both those which the customer is subscribed too, and also to those Services which the analyst's logging the requests team's Support. This is based on the teams defined as supporting the service on the service record. There isn't currently an option to limit the services based request type, but as soon as there is progress on this i can let you know. Hopefully the feature to enforce the use of a catalog item under a service will also help once the next Service Manager release is available. Steve

Hi @DeadMeatGF This can be resolved by removing the rights for the analysts to raise Known issues, by doing this, they will not see an option to select Raise a Known Error, or see the Known Error option on the Analysts Request Type Progressive Capture Form. If the users have say the Problem Management role, this includes the createKnownErrors application right which is perhaps why they can see this option. The above is a system role, which also includes the problem management rights as well, so you may want to create a temp role with only the appropriate system, database, application rights etc which could be a carbon copy of the above minus the known errors rights and assign these to the analysts for the time being? Hope that helps Steve

Thanks for the question @DougA In the next Service Manager update there is a new feature, which will allow you to 'enforce' that a Catalog item is chosen under a service, on the Service Details form in Progressive Capture. So in your scenario, if you have only configured say Incident Catalog Items, they will have to choose one of the options, not the parent Service in order to proceed. The same is true if you only had Service Request Catalog items defined and or a mix of the two. This will be configurable through a system setting which will be explained on the wiki once the next SM update is released which is likely to be in the next week or so.... In the meantime if you configure the Request Analyst Type form before the Services Details in Progressive Capture, then once the analyst has chosen a request type, only the Catalog Items for that request type will be displayed under the Services on the Services Details form (but this will not currently prevent the parent service from being chosen - the next SM release will address this). Hope that helps Steve

Hi @Ralf Peters I'll post back when the SQL Schema Designer reports also support this. In the meantime, there is one option open to you, which would allow you to use the entity reports option. When you are creating your Progressive Capture questions, you can choose to map these to the extended fields of the request entity. the following wiki article, and the last section Mapping Fields from customised forms describes how to do this. https://wiki.hornbill.com/index.php/Progressive_Capture_Designer The PC questions would still appear in the questions section on the requests, but the answers would also be held in the custom fields on the request forms. This has a few benefits. 1. The original answers as provided by the customer or the logging analysts would be held in the questions section, but you would then also be able to change the answers if you needed too via the Details section on the request form if you map the answers to the custom fields. meaning you would have the original and the current answers if this is relevant. 2. You would be able to include the answers to the questions in email templates, because the answers would be in the extended details columns for the request entity 3. You would be able to include the answers in the entity reports and change the column display names because the answers would have been mapped to the extended columns of the request entity. So in the example below i am using the Request entity, and including the custom_a and custom_b columns from the extended information table which is where i have mapped my custom questions too from progressive capture custom forms. Just a thought ahead of the SQL Schema Designer option being available and also possibly offering you a couple of additional benefits for using answers in email templates (as variables) and if the answers to questions needed the option to be changed during the lifecycle of tickets. Steve

Hi @Prathmesh Patel Sorry, that was a bit of an omission on by part. In the user app, if you go to the co-workers profile view, and if you have the appropriate rights to use the form designer, you can add the additional fields to the profiles - about tab If you select + Design and use the + to add a new field, this will by default be called Attribute 1 - you can rename this, to say Status and choose what type of control field it is, text, drop down etc. Once you hit apply, you will be able to via the cog on the field, make choices like adding field input validation, make it mandatory, and also decide if the field should show on the profile view even if blank. Once you have added the field, ensure to hit 'Apply Changes' for this to be saved. Once saved, if you view the field via the admin tool, profile, or in Progressive Capture you will see the display name you have given the field. You can also via the form designer, drag and drop fields between the different sections - so if you want this in another areas other than 'Basic Details' simply drag it into the appropriate section. Hope that helps Steve

Hi @Prathmesh Patel You can use custom fields against your users records to record this type of information - Once you have this you can do a few things with it. 1. On the Progressive Capture 'Customer Search' form you can decide to include this field so your analysts are aware that this user is a VIP when they are logging tickets. Here you can add additional display fields - and in my example the Attribute 1 field. This results in this in the following for the analyst in progressive capture 2. In the Business Process you might have an optional checkpoint defined which indicates if the customer of the request is a VIP. This can be evaluated when the request is logged using the Automated Task Node > Entity > Get Information > Get Customer Information followed by a Decision Node, and a custom expression to see if the custom1 field holds the text VIP and if so mark the optional checkpoint which will be marked and visible to analysts on the heads up display of the process at the top of the ticket form ** Note if you have this checkpoint in your process and you have chosen to allow customers to see the head's up display via the service portal, they too will see the VIP flag - so you may not want to take this approach, or choose to hide the checkpoints from being displayed on the portals - this can be configured per service in the Services form. 3. New Service Level Agreements You may want to consider using the new SLA functionality and definable Service Level Targets. https://wiki.hornbill.com/index.php/Corporate_Service_Level_Agreements If you are using the default With this approach you could ignore option 2 and define a VIP Service Level Target, and then using the Rules Builder in the SLA's you can set a rule to check if the customer is any one of your defined VIP's, and if so the VIP Service Level Target would automatically be invoked (it does not need to have any different response or resolution targets to a normal request, but the display name would indicate that it was a VIP customer and ticket. In my example below i have a SLA called 'Internal Support' and a Service Level Target called 'VIP' in the Information section of the ticket. Just some ideas but hopefully this gives you some ideas to think about Steve

Hi @Martyn Houghton The escalation actions are available with the new SLM functionality, they are defined under each Service Level Target in each Service Level Agreement. The following wiki page details the Corporate Service Level Agreements, including the escalation actions, and the video shows where these are configured and used. https://wiki.hornbill.com/index.php/Corporate_Service_Level_Agreements Hope that helps Steve

Hi @Melissa Gurney You should not have to refresh to see updates on the request details forms, for example if a customer adds an update from the portal into the timeline, you should see this immediately. Equally if you complete tasks or other actions which should change status, service level timers, or mark checkpoints on the heads up display these should also be instant. The same is true for updates in your newsfeed, workspaces etc. If this is not the case i note you have a premier support, so can i suggest you log an incident for this so the team can take a look for you? In regards to the request list view, this does not auto-refresh, but it is refreshed each time you do anything on the list, change view, open a request, switch to the personal dashboard etc etc. There is also a reload option to refresh the data manually as well if needed. Thanks Steve

Hi @Melissa Gurney Are there any specific pages this relates too? request details etc? Thanks Steve

Hi @Melissa Gurney Our default position is that all teams, can see all services and all requests logged against them so you will need to lock down the supporting teams on services to enforce visibility and assignment options. Possible Approach 1. If you want all teams to see the two services then simply leave these services as 'This Service is Supported by all teams' - this will allow all teams to log requests against these services, see requests in the request list and be able to assign requests against these services to any other team. 2. To ensure that This specific team does not see requests raised against your other services, you will need to add supporting teams against all your other services (obviously not adding this team) 3. There is a Service Manager Setting - servicemanager.progressiveCapture.servicedetails.enableSupportVisibility - The default setting for this is 'Off' When the setting is 'On' the Services displayed on the Progressive Capture Service's form will be filtered to both those which the customer is subscribed too, and also to those Services which the analyst's logging the requests team's Support. You can find this setting in the admin tool, under service manager and settings. With this option on, the members of this team would only see the two services they support on the Service Form in Progressive Capture when logging requests for customers. I hope this helps Steve

Hi @Ralf Peters Just to let you know that the admin console has been updated and the ability to change the display name of the report columns is now live. This is available on reports created against entities, and measures initially, with the SQL Schemer Designer to follow. When creating reports based on Entities, if you select say Requests this will allow you to report on all the data held in the tables linked to the request entity including the custom fields held in the extended info table, request info, raisedby etc etc without having to use the SQL Schemer Designer to join tables. Once this is available with the SQL Schema Designer i'll update the post Steve

Hi @gregmarcroftorc @nasimg Just to let you know that the admin console has been updated and the ability to change the display name of the report columns is now live. This is available on reports created against entities, and measures initially, with the SQL Schemer Designer to follow. When creating reports based on Entities, if you select say Requests this will allow you to report on all the data held in the tables linked to the request entity including the custom fields held in the extended info table, request info, raisedby etc etc without having to use the SQL Schemer Designer to join tables. When SQL Schemer Designer column display names is available i'll post back here Steve

Hi @Awalker The requirement has been accepted but it is not in our currently scheduled list of stories, so i can't give an exact timeframe on this i'm afraid. As soon as it scheduled i will post back here and we will have a timeframe to work with. Just because it is not scheduled today does not mean that won't change quickly, and one factor which helps us prioritise, is the number of customers who are requesting / supporting features. This particular requirement already has a fair bit of support from other customers so is very high on our radar for inclusion. Thanks Steve

Hi @Ralf Peters There isn't an option to convert a request type once logged, due to all the differences which may exist (business process aspects most importantly - this drives assignment, notifications, tasks, Service Levels etc). the idea is that the end user should not care nor be aware of the ITIL type request they are making, they should just be presented with a list of non technical catalog items which have been configured in the backend to raise the relevant type of ticket (Incident or Service Request). If the user has chosen the wrong catalog item, then the request type will only be one concern, i suspect the fulfilment Business process will not be correct either, as it will be specific to the catalog item they choose - therefore the only option would be to raise a linked request of the correct type and correct catalog item against the original request. Hope that helps Steve

Hi @Shamaila Yousaf I believe Chaz was referring to an issue where the request type for a ticket was incorrectly being set, and this has now been resolved. Service Manager provides you with the options on a service by service basis, to configure the Request Catalog options which will be presented to the customers on the portal. You can decide what request type you want the Request Catalog Item to be raised as (An Incident or a Service Request) this removes the need for the customer to have to make any such decision, they can simply choose to select the assistance they need, and the system will take care of raising this as an Incident, or a Service Request as you have configured it in the Service record > Request configuration section. It looks like @DeadMeatGF has indicated that you have Service Request options configured, but these are set to draft which means they will not be visible to the customers on the portal. With the required request catalog items defined there should be no need to switch the request types, as they will always be logged based on the configuration choices you have made. In my example below i have a Service Request Catalog item defined against my Mac Support service which will allow my customers to make a request to have their Mac deep cleaned, and this will come through as a SR, if i want to offer more catalog options i simply create them under either the Incident or SR tabs on the Services form. I hope that helps Steve

Hi @Kelvin On the Contact forms, the default and custom fields can be made mandatory. You will need the rights to use the Form designer, but if you edit a field (Using the cog), and in the example below i have used the telephone field - if you tick the This field cannot be blank when saving and hit Apply, and then ensure you also save your form design changes, the field will then become mandatory. Mandatory fields are denoted by the red line on the lefthand edge of the field. Hope this helps Steve

@Ralf Peters Just a quick update here for you. Earlier in this post you asked about the ability to change the report column titles if creating a report using the Service Manager SQL Report Creator. We have added the ability for you to do this in the admin tool, and it is currently going through testing before it is released. This will allow you to set your own column title display names on the reports and these will be present on both the HTML and CSV outputs. This will allow you to define meaningful display names for the custom fields if reporting on the extended details table custom columns for example. Please keep an eye out for the release notes in the admin tool, but i will also post back here once this change is available to you (should be available very shortly). Steve

Hi @gregmarcroftorc Thanks for the post, we have recently implemented this, and it is currently in testing but we expect to be releasing this to live very shortly. This will allow you to provide a user friendly name for the report columns and this will persist and will use these names on both the csv and html outputs for your reports. Once this has been released to live i will post back here, but look out for the release notes updates in the admin tool. Thanks Steve

Hi @gwynne Is this for automated email replies? Using the email templates you can already include the request variables in those templates. We also introduced the ability a while back to allow the mapping of question answers into the custom fields of requests, so that you could include those answers in the email templates. There is some info on the wiki about mapping answers to custom questions to request fields here, and then in turn using them in email templates: https://wiki.hornbill.com/index.php/Progressive_Capture_Workflow Or where you thinking of something else? Steve

Thanks for the update @Bridget Sharman i'll ask Armando to look into this

@derekgreen Just so i have this correct - the email field text is greyed out? i can't quite see on the image? you can't type into the email field to change it? i would expect the Save Changes to be greyed out but not the text in the fields? Also i notice from your screen shot that it looks like you have the Service Portal and the Live app open in other tabs - are you logged in as the same user in those interfaces as well, or are you in as different users? i am just trying to rule out if it is anything to do with some confusion as to which user session is active in the admin tool if you are also logged into the other two instances perhaps as a different user with different rights? Let me know and i'll see if i can get to the bottom of this for you. Steve

Hi @Bridget Sharman We have found an issue with the saving of the assets, if the length of the usedby or ownedby exceed 64 characters, this has been fixed and will be available in our next update. Could you confirm that if you update the values in the Location and Site fields together, or in fact any combination of fields (not the usedby or ownedby) that you are able to save? so that we can be sure that the fix will address your issue when it is available? Thanks Steve

Hi @Dan Munns Not as of yet i'm afraid, as soon as i have an update of when this is scheduled i can post back here. It is not a big change, it just needs to be scheduled in along with our other priorities, and once it is i'll be able to give you a better indication of when it will be available. Steve