Steven Boardman

@m.vandun If i get what your saying here, basically the customer emails in and you want the owner to deal with their response? would the following work in this scenario. Essentially the new feature is status based so, via the portal the two options would set the status to Open or Closed based on their response when it is resolved, and if no response is received then it would expire and i assume you would set it to closed on that branch in your business process. If the customer emails in and the owner is notified and reviews their email, could they not do the following: 1. If the customer is accepting the resolution they manually close the request, or let is expire resulting in the closed status which you want. 2. If the customer is not accepting the resolution the analyst sets the status to open manually and then continues to work on another resolution (in my example create task for them to do so)? Once they have another proposed resolution they communicate the resolution and putting the request back into a resolved status thus going back into the two stage closure loop and giving the customer another oppurtunity to accept or reject the resolution via email or the portal? This just basically means the owner of the request has to re-open the request manually if a response is received via email - as we don't know what the content of the email and the update is until it is reviewed. Would that help?

@sprasad thanks for the post Whilst it is not currently possible to do this from the single customer progressive capture form, this information should be available to you in the context of supporting external organisations If you include the Organisations Details PC form after your Customer Search PC form, then you will see the Active Requests for the customer's organisation listed on the second PC form (as shown below), you will also have seen the individual customers active requests on the first PC form. In my example PC flow, i have a scenario where we support internal colleagues (co-workers), and external contacts, so i don't want the organisation details form showing each time i log a request against a co-worker, so i do a simple check on the type of customer i am raising the request for, and if it is a contact, show their parent organisation details form, if it is internal don't. @Kelvin this won't help you if your customers are all internal, but i'll raise the topic of adding additional configurable tabs the the customer details form where we can explore providing options to include not only active, but site, company grouping and even closed requests for the customer - i'll report back here as we are able to progress this Hope that helps Steve

Hi @Paul Alexander There was a defect which would leave Closed requests in the Awaiting Feedback list even if their expiry periods had expired. This was fixed on the update you are running, so this should not be the case for any new requests. If you have any existing Closed requests in this list, if you open them up you won't see the option to provide feedback (as the option has expired), but by opening the request this should then remove it from the list of closed requests in the Awaiting Feedback list - so kind of gives you a way to clear down any historical one's where this issue existed. Finally the expiry feedback period is calculated on a 24hour Mon-Fri calendar from the point a request is closed (not linked to each request's SLA and it's WTC). I hope that makes sense? Please let me know if you still have an issue for new requests logged since the last Service Manager Update, and they are still appearing in the Awaiting Feedback list after the feedback period has expired, or if you are not able to clear down the historical ones' from this list by opening them? Thanks Steve

Hi @Keith There is a new Suspend Await Status Change node in the BP designer, which is on the wiki here. https://wiki.hornbill.com/index.php/Service_Manager_Business_Process_Workflow I have this in an example below: So after the request is resolved, i use this node and say it is only valid if the request is an status of resolved. I follow it with a decision and possible outcomes: 1. Expires - Expire Period is set to 2 mins in this node, and on the status not changing, it will follow this route and my example > next stage and will move to closed in another node in the next stage. 2. Customer Accepts Resolution on the portal - or in other words status is set to status.closed in my decision branch and it moves to the next stage 3. Custom Re-opens the Request on the portal (choosing it's still broken) - or in other words status is set to status.open in my decision branch, and it then get's who the owner is (get request info node), and creates them a task for the owner to look into why it is still an issue - and following the outcome either loops back through the two stage closure (customer acceptance) loop again, and again and again etc if the customer keeps rejecting the proposed resolutions in the window i have created in the Expires Period, but automating the status to revert to resolved before it enters back into the Suspend await status change node on each loop. or in my example if i have spoken with the customer and they are happy verbally i go to close immediately. This is just an example but hopefully gives you an idea of the logic you could use off the back of the suspend await status change node, following a request going into a resolved status. Basically build branching for status changes or expired: * Expired * Status.open * Status.closed Being the main ones to consider in this scenario Hope that helps Steve

Hi @Paul Alexander The request feedback can only be invoked when a request is closed. So the period of days you have set for the feedback to be valid for on the service , will start from the point the request is closed. In the screen shot you submitted i can see that their is one awaiting feedback, and when you move from an Active Filter to the Awaiting feedback, you only see the one closed request where feedback is requested. So if you want to give them 14 days to provide feedback, it will be 14 days from the point of request closure. The Green Awaiting Feedback button is shown on all filters, including Active but it is not to indicate that active requests can provide feedback, it is to let them know they have other closed requests where feedback is sought. And clicking on the Awaiting Feedback button will take them to that list I hope that makes sense? Steve

@Shamaila Yousaf we have a story for this functionality and i have added you as an interested party for when there is an update on it's progress and scheduling

@Darren Rose @Dan Munns i am pleased to let you know that catalog items will be available against changes in the next Service Manager update, which is expected later this week. I hope that it will prove useful Steve

@Dan Munns with @Victor suggestion you could write the answers from the different custom fields on the request, and then use a get request info node to populate the variables into the task details box? In addition in the next Service Manager update, which should be towards the end of next week, there will be a new Business Process option Under Get Request Information called Progressive Capture Answers, this will supercede the Get Request Questions (which will still be available) but you will not need to specify the PC form id when you use this node, instead in the Variable Picker, you will be able to select the PC form (or in your case forms) and the questions you want to include in this example in the Task details (another advantage is the questions will be the actual question named, not Answer1, Answer2 etc which is how they are available in the current Get Request Questions option). New Variable Picker options in next Service Manager update: This will result in the answers for different questions on different progressive capture forms being able to be added to the task details I hope this will help Steve

Hi @Dan Munns I think the feature you are referring to is documented here on the wiki: https://wiki.hornbill.com/index.php/Service_Manager_Experimental_Features If you have this setting enabled and the relevant roles attributed it should work as described. if this is on and not working let us know? Steve

Hi @lee mcdermott I am sorry you are having this issue, can i suggest at this point the quickest way to get this looked at is raising this as a support issue here: https://www.hornbill.com/request/ Let's see if we can get to the bottom of what is causing this for you Steve

@m.vandun Great stuff happy to help

@m.vandun One option is to write the outcome of the initial task 'is an installation required' task to a custom field on the request from (against the service), and then on entering the 'install' stage use a get request info node, followed by a decision node and evaluate the value in the custom field. If the value in the custom field is 'Yes' then branch and create the Human task for installation, if 'No' then branch and do not have a human task to do the installation? should save an unnecessary task? You can use the Update Request node and the variable picker following the initial task Steve

@m.vandun if you added another stage, it would as you say also show on the head's up display so probably not practical. if your process is more involved (and it looks it), and you have parallel processing, would the logic still not be valid, as you could still complete all other streams within your parallel processing and then maybe evaluate the outcome of the specific 'is an install required' task outside of the parallel processing, once all other aspects of the 'info' stage are complete, and then you branch either to the install stage or another? Sorry if i am misunderstanding this (it is a very hot Friday afternoon) Steve

Hi @m.vandun Could you have a human task in stage one (info) and a decision after it and two task outcomes (Yes / No) for if an install is needed. The First decision branches and uses a Next Stage Node (configured to go to the Install stage) and an Install task in the Install stage The No decision uses a Next Stage Node (configured to go to the End Stage and bypass the Install Stage and install stage On the next stage nodes you can choose which stage to go to (as long as it's forward) This is not transferring a task to another stage, but if your task is pre-defined in the install stage and your logic is only go to the install stage if an install is needed, then you should get the same end result? Hope that helps Steve

Hi @Lyonel If you are assign the request so it is owned, you should then see the resolve / close options Hope that helps Steve

Hi @cchalmers Looking at the error, have you defined the Progressive custom form ID in an entity Get Request Information > Request Questions node before trying to use the variable picker in an Update Request Node? So initially populating the following node and Form ID field with the ID of the Progressive Capture form - so change the form id from Auto to Manual and then define the form ID. then follow that with an Entity Update Request > Details form, and then you can use the variable picker to choose the answers you want to populate into the summary or description fields? Hopefully this helps Steve

@Tina.Lapere We are holding the event on the 28th at: DoubleTree Hilton West End 92 Southampton Row London WC1B 4BH I have asked for the details to be emailed to you so you can review and register formally if you are able to attend

@Joyce There are a number of example measures, widgets and dashboards on the sandbox instance, where you take take a look at queries etc. One Example dashboard containing List of Counter widgets is shown below: The Incidents logged today in this example was configured as follows: You can take a look at these examples on the public sandbox, and get access to it by requesting access and getting emailed access details from here: https://www.hornbill.com/try-now/service-manager/ This instance has it's data refreshed nightly, and we are always adding new examples. Hopefully it might be a useful resource for examples of widgets etc. Steve

@cchalmers this experimental feature would allow any member of any team which supports the service against which the request is logged, complete an activity which is assigned to another user. So supposing you have defined teams which support the services which you offer, then even if the request is reassigned between those teams which support the service, then anyone in any of the teams which support that service would be able to complete the tasks. Of course this is all audited in the task, and the timeline of the request, so you will know who has completed the task. The link above gives more detail, but in essence the feature would need turning on, and any analysts who you wanted to have this ability would need one of the following roles: Incident Management Full Access, Change Management Full Access, Problem Management Full Access, Release Management Full Access, Service Request Full Access Finally, if you didn't have team's defined against your services (i.e. all teams could support them, then it would be limited to the membership of your specific team). @DeadMeatGF would the above feature work for your facilities teams? i would need to confirm this is also supported on the mobile, and if not look at extending this out. In terms of the reassignment of tasks, on reassignment of the request i am not aware we have anything in the pipeline at the moment. What i would comment on, is in your business process, if you used the Get Request Info node, and checked for the current Owner in front of each task node, and then used the Assign to Owner variable on the tasks, it will mean any subsequent tasks would be assigned to the current owner of the requests. Obviously this would leave the one / s which are currently active, to deal with either through the owner, reassigning them, or utilising the above experimental feature, which would allow other members of their team to complete tasks which are not directly assigned too them. Hope that helps

@derekgreen Welcome back Would you be referring to the Export Option on the Request List view? if so this is still there as shown below: If you are viewing the list on a small resolution screen, or have the window reduced you may not see the icon as shown below: If you put the window into full screen do you see it again?

@cchalmers it isn't possible to de-activate notifications for certain roles at this time, obviously if this changes then we will post back and advise. Did you consider the alternate approach using the experimental option i mentioned above? As i recall you wanted to avoid the single point of dependancy, and the ability to complete someone's else task on a request (if you belong to the same team) would give you that, and would avoid the noise of the notifications which are being received by everyone with that specific role. https://wiki.hornbill.com/index.php/Service_Manager_Experimental_Features In my example, if user A is assigned a task, User B, or User C who are in the same team would have the ability to select and complete the task, even if it was assigned to User A, without the need for a manager / supervisor to have to re-assign it first to User B or User C. Hope that helps

@SJEaton From the h_sys_tasks table, you can include the h_completed_on column, which will give you the date and time the task was completed. As Victor points out, there maybe multiple tasks per request, so you could group the tasks by request as per my example earlier in this thread, or if you are interested in the completion of a specific task on all requests, then you could add a filter to the h_title column of each task - so that the report only returns tasks that match, and of course their completion date if you include the suggested column above.

Hi @SJEaton As Conor says not currently, although we are looking at option for versioning in this area - more news on that once we are closer to making this available. One suggestion i could make is that once you have created a Procap or Business Process, you can use the Download option and keep a copy of that anywhere you like. This is a the process definition as a .txt file. In the event you deleted something, you could simply create a new process with the same name, and then upload the saved definition which you downloaded. These are the upload / download options i am referring too. Hope that helps, and we will post more on the versioning in due course Steve

@SJEaton I am not sure if this is what you are looking for, but you can include the task completed on column from the h_sys_task table, and then if you create a report as a Grouped List of Data type, you can then group the report on the Request ID, giving you something like the following: In my example i have chosen to re-label the column names, and exclude the request ID from each row, which you can do under Data Collection tab > Select Columns > Marking the Column as Not Visible Hope that helps

@SJEaton If you are looking to join the h_itsm_requests table with the h_sys_tasks table the following may help: When defining the join, use the Against Custom Criteria which will allow you to ConCat the h_obj_ref_urn column value, as you want to join on the last part of the value, with the request id in the h_itsm_requests table (h_pk_reference) Example of a URN: urn:sys:entity:com.hornbill.servicemanager:Requests:IN00000344 So you can use the following in the Against Custom Criteria: CONCAT("urn:sys:entity:com.hornbill.servicemanager:Requests:",h_itsm_requests.h_pk_reference) On the Select Columns tab, you can also click on each selected column to give it a more user friendly display name Hope that helps Steve