Steven Boardman

@Claire Holtham Currently that is correct, you are not able to raise Changes from Self Service - this feature would provide you with the capability to offer this if you wish. You can currently provide the ability for your customers to raise either Incidents, or Service Requests. Off the back of which you can raise a linked Change, if something needs to be changed / managed formally - using the link request action option on the requests. If you do raise linked changes from Incidents and or Service Requests, there are business process options available to you to automatically update the originating request (Incident / Service Request) as the change progresses, and in fact when the Change is closed, you could if you wanted automate the resolving / closing of the originating Incident / Service Request using the Resolve Linked and Update Linked Request business process options - more info on this is available here, if you scroll to the Linked Request section https://wiki.hornbill.com/index.php/Service_Manager_Business_Process_Workflow Hope that helps Steve

Thanks @Claire Holtham I have added you as an interested party to this development feature, and i will post back once this is started. Steve

Hi @Bob320 The timers for fix and response goals will be configured in the business processes you have defined using the business process engine, accessible via the admin console. You may have one business process for say Incident Management, or you may have different business processes for each different service against which you can raise Incidents. In the second of these scenarios it maybe that you have start timers configured in some business processes and not others? In either case the first starting point would be to have a look at the business processes and see if you have the nodes which Start the fix and or response timers once a ticket is logged and a priority is set. 1. In the admin console you should see your configured business processes listed, similar to my example below. 2. In each Process, a fix timer will only be started if you have configured it to do so by using the Start Fix Timer Node as my example below shows 3. If you have configured different business processes for the different services you offer, you can see which business processes are defined and in use against each service you offer in the user app under services > Request Configuration > Request Type > Workflow as shown below In this case 'Desktop Incidents'. 4. You may also be using Catalog Items, as shown in the example above, and in which case you can also check and see which business processes have been configured against each of these catalog items, again to see if those business processes are configured to have the Start Timer node (and subsequently the Stop Timer nodes) configured. Hopefully this will give you somewhere to start looking to see if the start and stop timer nodes are configured into all or some of your business processes which support the services and catalog items you offer? let us know how you get on Steve

Hi @SJEaton If you are getting a stage checklist validation error it is usually because you have tried to exit the stage, and Mandatory Checklist items have not been marked. When you are creating your first stage, and setting checklist items, you have the choice to mark these as Mandatory, or Optional. If you have a scenario where the request is going to be cancelled (as you appear to have) then this should be an Optional checklist item, but so should the other checklist items which exist in this stage which may come into play if you don't follow the cancel path, but instead follow the MSS / ESS 'no' option in your example. If you set your checklists items to optional this may do the trick What we are basically saying is, we have two possible routes this process could follow, and as down either route we have checklist items, but because we don't know which route will be taken at design stage, we need to set the checklist items as optional. Let us know how you get on Steve

@lee mcdermott There isn't an option to select a service in the BP, this is generally because the BP itself is selected when choosing the service (if that makes sense). The only real exception to this is where you are not using services, and are using a default BP against a request type through the system settings. If you enabled the Change Management Request type against your different services, this would allow you to define (if required) different BP's for change against different services (or use the same one), it would also allow you to add the relevant Supporting Teams as @Ehsan has suggested to each service, allowing members of those team's visibility of the changes, and also the option (again if required) to assign the change to those teams if needed. But it would still require the selection of a Service 'to change' during the Progressive Capture logging process. One other approach which you might want to consider is using a single Change BP which assigns the change to your change management queue (team), and instead of having supporting teams viewing the whole change - you could when you are creating your tasks / activities for the teams who are completing work on the change, pass information into the task descriptions from the Change, which will allow the team to complete their task with a sub-set of information from the change (but they would not be able to view the change itself). To do this you can include variables in the task description which you are setting up in your BP - something like below. In my example i have used the BP nodes to get both the Change Request Info, and Get PC Answers before the Authorisation node, which in turn allows me to add variables such as summary, or values in the custom fields, or answers to Progressive Capture questions into the task / approval description) Which would give you something like this on the task (or approval in my example) Now this won't give the team assigned the task access to the change, or all it's content but it might be something to consider, although i suspect the use of supporting teams on services is probably going to work better for you. If this is of interest, there is more info on the wiki of working with variables: Request Variables: https://wiki.hornbill.com/index.php/Request_Variables Also if you wanted to map Progressive Capture answers into Custom Fields of a request there is more info here: https://wiki.hornbill.com/index.php/Mapping_Fields_from_Customised_Forms Steve

Hi @Rohit Govind We have just checked and your instance seems to be fine and is accessible, with no errors in the logs. You can check this yourself by going to our support page and entering your instance details, and performing a ping check. https://www.hornbill.com/support/ Let us know if this is not what you see Steve

@samwoo The requirement to view requests which you are connected to from the portal does exist but is a little way down the queue, i will of course add you to this now and again this will help bring it forward Thanks Steve

@DeadMeatGF no problem i understand the use case and have added you to the interested parties

@samwoo done Just to reiterate, getting community support for features really helps us prioritise the order and which one's we can add in so thanks for adding your support on this one Steve

Hi @Paul Alexander I've just checked and this development story is still outstanding and has not yet been scheduled. I have added you as an interested party and this in turn helps to move it forward in the priority list. As soon as this is scheduled i will post back to let you know Steve

Hi @SJEaton The parallel processing would be specific to each stage, so you would need to use the Start Parallel Processing and the Finish Parallel Processing nodes in the same stage, with the required tasks or other activity defined in between. Below is an example where i have two streams of tasks occurring within my parallel processing, and they then come back together. In this example, the Configure Equipment and the Add User to AD will be created in parallel, but i don't need the Add User to AD task to be completed, for the Install Applications task to be created once the Configure Equipment task is complete. I hope this helps Steve

@lee mcdermott If you wish to add a Service Level Target to a Service Level Agreement, you can do this from the Service Level Agreement as you have indicated. If you highlight the SL as per the screen shot below you will see the option to add Targets on the right hand side, and you can use the +Add Target to add a new Response or Resolution target for that Service Level Target. If you have this set up, on the request itself you would need to change the Service Level Target manually from the Request by clicking on the Service Level Name in the information section - In my example below - Internal Support Low Which will bring up the pop up. From the pop up you can choose the Service Level you wish to change it to, and provide a reason for the change of Service Level Target. This will then update the Service Level Target on the request. A couple of things to note here: * Currently once the Service Level is set during the logging of the request, the Rules you have set will not re-evaluated when you say change the Priority, hence the need to manually do the above. (We will be introducing the ability for the rules to be applied post logging on say priority change but it is not here today). * If you change the Service Level Target it's response and resolution targets will be re-calculated from the point the timers where started not when the Service Level was changed (so you could see these immediately breach if your SL target has already passed) In regards to incorrectly logged tickets, then yes using the Link and Raise linked request would be the option as you can't change a request's type after it is raised. Steve

Hi @chriscorcoran You can use the reporting tool to create a report on the h_sys_profiles table where the call categories are held, and then use the option to export the report to CSV: This won't tell you which services you have have these configured against, but it will let you know which categories you are dealing with as a starter. Steve

Hi @dconagh Are you looking to report on the name of the external companies you support and who reported the issue from these companies? so in Hornbill terms the Contacts at each of your organisations you support? If so you could create a report with no joins to get this information using the Entity reports option available in the Reporting tool. When you create a new Report, in the General tab, set it up as follows: * Report Using = Entity * Report Entity = Request This will then provide you with all the related entities and their information, along with the main Request Entity, so namely the customer contact info. If you look in the Data Collection tab, you will see a long list of the the entities, and the available columns, which you can include in your report. In my example below, i have included the following: * I have also used the option next to each column (notepad and pen icon) to give each column a nice display name by clicking on it an editing the default table value (for display purposes only) * Note you can also reorder how the columns appear on the report by dragging and dropping them into the preferred positions on this view. Once you have the columns selected, you can preview the data as below, and if happy save and run the report exporting then to CSV or HTML. you still have the select filter options available to you should you wish to filter the results down based on dates, request type, company name etc Steve

@Tina.Lapere That is correct - the setting you mention is for the customers who use the Service Portal not the customer portal. So anyone that goes to service.hornbill.com/<yourinstancename> Steve

@Sonali In addition to what Chaz has highlighted you also have the quick filter on the request list view, which if you have the Problem request type selected or you are working in a custom view you have created, you can do a quick search against the Summary text from the quick filter box on the left hand side - Users in my case below against Problems belonging to any Services my teams support. Steve

@Lyonel Just an update here to let you know the types - Static and Dynamic Radio sets have been added to the progressive capture custom form field type options, and this will be available in the next admin tool update (should be later today). Steve

@Paul Alexander So it sounds like we could achieve what you are looking for by expanding on the Get Request Information BPM options we already have. We currently have the Get Customer Details and the Get Organisation Details (which looks at the customer to work out which organisation details to retrieve) We could look at adding a Customer Grouping option, maybe with input parameters which you specific the grouping type: Cost centre, Division, Department, Company etc - and you just decide which grouping type you want to get the info for (i.e. the one which contains the attributes where you would hold the codes). And then following this node you would use an Update Request > Custom fields to write these values to the required custom fields of the request, and so could be used in the email templates. There are some challenges with this, such as a customer belonging to multiple departments or divisions, so there is a bit to consider. This change is not currently in our deliverable list, but i will post back here once it gets scheduled and we can progress it Steve

@paul.alexander Yep the idea would be to hold the information in the customer attributes as this is then available to be included in the email template as an email variable. We are always adding to and expanding the Business Process nodes and operations, we are trying to provide an environment which is parameter driven and we have evolved the options which you see today based on customer feedback. Whilst we might not a SQL query solution there might be other options we can look at which provide the same result, if we can understand the use cases? An example of this is our next step into automation and orchestration in the business process engine which we will be updating our customers on in the coming months. This was discussed already on the forum here, re an alpha WebCall which is not for production but gives you an idea that we are busily working in this area and will be able to talk more about this evolution soon. Steve

Hi @paul.alexander@vinci.plc.u The data which you can include in the email templates which can be fired from a business process automatically can include extended data of the related entities to the primary entity, in this scenario the primary entity would be the Request, so here we can include attributes of related entities to the Request namely: * Customer * Organisation * Service * Owner * Raised By * Team Now in your given example it sounds like there maybe an approach which can be discussed, but this maybe subject to where you currently hold the information about the following (outside of Service Manager). * The Air Time contract code for each division and the division the customers customer belongs too * The Hardware Account code for each division and the division the customer belongs too Now if we can use a combination of our import utilities (LDAP & SQL) we could map this information into the custom fields of your supported customers and then as we have this information in those attribute fields for the customer of the request we can use them as variables in the email template: There are a number of things to discuss and aspects which are specific and may rely on where your data resides, so i have spoken with the Product Specialist who is working with you and he will go through the options with you tomorrow afternoon on your next session to see if this approach is applicable to your requirement. The question about the asset product code might also be one to pick up with your product specialist, as i am not clear on how you are presenting the Asset options, as it sounds like you are looking for a shopping cart type experience, where you can pick a product / products and order them? unfortunately we don't have this type of functionality at the moment. In the absence of the above, one approach could be to use a custom question in progressive capture to see which type of mobile they require, and then once the request is raised, you can evaluate the answer given in your Business Process (GetRequest Question > Decision > Custom Expression > UpdateRequest - Custom Fields (**Available in next Service Manager build), and if it was Mobile option 1 - then update custom field 1 of the request with a specific product code 1, if it was Mobile option 2 - then update custom field 1 of the request with the specific product code 2 etc etc Once you have a product code in the custom field of the request, then it can be included in an email template as a variable. The above maybe feasible where the options are limited, but i am not sure it would scale but i just wanted to propose something for further discussion. Steve

Thanks @samwoo I think that is a great idea about getting some of this content / FAQ's etc on the wiki and i'll certainly look at the best way to do this / present this. In regards to the connections of an Incident / SR, they do not currently see these requests via the portals, but it is again a nice idea. I can see several use cases, including the obvious one, of raising a request on behalf of someone else. We have a story in our queue which relates to adding connections as part of progressive capture, so this could be a natural evolution of that. I'll post back here when we have made progress in this area Steve

Hi @Sonali Connections can be used for a variety of purposes in different request processes, but there maybe other options for the scenario you mentioned in Incident Management. I would think that you could look to record each Incident as a separate record, so if one customer has reported an issue and another customer calls in with what sounds like the same issue, i would still record these as separate Incidents. If we start to see a pattern developing then you could either group these Incidents under a Major Incident, using the Link Request Feature - and then from the Major Incident you could use the Business Process options to Update the Linked requests at key points, and or use the Resolve / Close Linked Requests feature from the Major Incident to the child Incidents once the Major Incident is resolved. One of the options with the Resolve / Close Linked request feature is the ability to email the customer of the linked requests automatically and also notify the owners of the child Requests. The above could also be true for the use of Problems and Known Errors - here again you can link multiple Incidents to a Parent Problem or Known Error. Where Connections play a nice feature in Problem Management, is the ability to publish known issues to your customers on the Portal, and provide them with a quick and easy way of associating themselves to said known issue, without the need to raise a new Incident / Request, and for the Problem Management team not to have to go looking for and linking Incidents to the Problem / Known Error. So from a Problem / Known Error record , you can use the Publish action, and this will make the known issue visible on the Service / Customer Portal, where customers can use the Me Too button to add themselves as affected users (connections) to the known issue. As Victor has suggested above, you can then use the Email Connections business process option in your supporting business process, to keep the affected connections informed of progress or resolution of the known issue via email automatically. To come back to where Connections could be used in Incident Management, you could add interested parties to an Incident and then again use the Email Connections business process option to keep them informed of progress, or you could also include them on manual communication you are sending from the Incident, by adding them in bulk to the cc or bcc fields based on their connection to the Incident (Interested, Impacted - bearing in mind the list of connection types is definable in a simple list in the admin tool). I hope that helps Steve

Hi @Prathmesh Patel There are a few things to consider here, the main one's being: 1. You would need to set up a new Service against which the security Incidents / Requests can be logged. 2. You would need to subscribe those customers who have the rights to raise requests against this service. 3. You would need to add the new Security support team and the Service Desk team to this service as Supporting teams this would achieve two things for you: * Only members of the supporting teams would see requests raised against the service in the Request List view * You will be able to restrict the assignment of requests logged against this service to only those teams which support it, and members of those teams. Other considerations / system settings you want to factor in. In progressive capture, if a customer calls in the analyst who is working through your progressive capture forms, may see the following two: * Customer / Contact / Co-Worker Search - on this form a list of the customers active requests are shown, and by default this list of the customers requests is unfiltered, meaning potentially an analyst logging a non security related request, may see one of the customers security requests in this list - albeit they will not be able to open it. In order to ensure this does not happen, ensure the following system setting is enabled - this is in the admin tool > Service Manager > Application Settings app.itsm.progressiveCapture.customerDetails.showOnlySupportedRequestsLimit the requests listed against a customer to those that are supported by the session analyst * Secondly if you want to keep the presence of the Security service restricted to only those who support it, you can also enable another system setting which again is in relation to the progressive capture process. By default when an analyst is logging a request for a customer, and they get to the Services Details form, they will see all the Services which the Customer is subscribed too displayed. If you only want the analysts of the Security Team, and the Service Desk to see this new service, then enable the following system setting: servicemanager.progressiveCapture.servicedetails.enableSupportVisibilityFilter Services in PC by teams that support the service as well the customer's service This will ensure analysts which belong to other support teams will not see the Security service when they see the Services form, as they do not support it, even if the customer they are talking to is subscribed too that service. Hopefully this helps Steve

@Sonali If you use the Quick Complete as mentioned above this will reduce the clicks too 2 Steve

@Sonali When you have an activity assigned to you, if you hover over the activity, you will see a tick in a box (quick complete) If you click on this, you will be taken straight to the complete view, where you can select the required outcome and from here you will not be required to then close the view, so this should reduce the completion of an activity to 2 clicks (unless you have made the adding of a reason mandatory of course). Steve