Steven Boardman

@Gary@ADL @Martyn Houghton @paul.alexander@vinci.plc.u Just an update on this requirement. The work has now been completed and will be available in the next Service Manager build, which should be available within the next two weeks, so watch out for the release notes. This business process option will allow you to update the custom fields of the request forms. You can either predefine values, or pass in variables such as the outcome of tasks, tasks descriptions, completion date of task, PC custom form answers etc . You will also have the option to append the updates to any existing text which is present in the custom fields already. As with the use of the Progressive Capture mapping to custom fields feature, consideration needs to be given to the TYPE of custom fields which you are updating, single line, multi-line, date/time etc to ensure the update values you are providing can be presented / edited (if required) in the custom fields on the request details section where the custom fields are displayed. Steve

Hi @Sonali There are two options for removing requests from the boards. 1. You can remove them manually from the board, using the trash can on the request card representing the request on the list, after you have reviewed them etc. 2. In your Business Process which is running for the Incidents, you can at whatever stage of the process (say after the response, or resolution timers have been marked, or perhaps after resolution or closure of the request or after a review, you can automate the removal of the the request from the board using the Boards > Remove From Board > Remove Request from Board and specifying the Board Name. If the request is not on the board when it reaches this point in your process it will simply ignore this node. We have seen customers wanting to leave breached or breaching requests on for review, or manually remove once reviewed, through to relying on their business processes to remove any from the boards once the requests are resolved, or closed. Another option is to use the remove from board, so it takes it out of the approaching breach list on your breach board when the response or resolution marker is marked, but then use a decision node in you business process which evaluates if it was fixed within target (Yes / No, and if it was not fixed in time, you can use the Add to Board options in the business process to put this into a Breached Service level list on the Breach board again for review or for your widgets which are counting on the number of requests in each list. Just some ideas Steve

Thanks @samwoo I can replicate the behaviour and i have passed this onto one of my colleagues to take a look into and comment on Steve

Thanks @paul.alexander@vinci.plc.u Would an approach to this be to use a Human Task in the business process, so after you have completed all of the work of the request, you have Human Task created, which within it Lifespan Settings, it's Start Date can be set to 60 days, which will be 60 actual days from the point the task is invoked in your process? This task can be assigned to a user, group, role or variable (such as owner of the request). The task can have custom outcomes, and it can also be set to expire if not completed in say 70 days which would allow branching based on completion or non completion in a defined time period, with whatever required actions defined in your business process. The task will appear on the Task lists, calendar and custom boards? as well as the Activities panel on the right hand side slide bar on all views. Is this something which might work in this scenario? Steve

@m.vandun @samwoo @Gary@ADL Just a quick update on this one, the work has been completed for this and will be available in a Service Manager update within the next couple of weeks, watch out for the release notes. Steve

Hi @Martyn Houghton @Melissa Gurney @paul.alexander@vinci.plc.u Thanks for the post, i have raised this internally and will feedback on what we can do here. Martyn thanks for your use case. Melissa, Paul - would you be able to provide more information on the length of resolution times you may need? Martyn has highlighted that the existing 40 Days actually already caters for say 120 elapsed working days if your working time calendar is set to an 8 hour working days, Mon-Fri as there are 3 x 8 hours in each 1 working day. So in the example above if i had a 40 day resolution target on a 9-5 Monday - Friday Working Calendar then this would be 21st September, 2017 from today. However if it was 40 days on a 24 hour 7 day working calendar it would be the 16th May 2017 from today. Thanks Steve

@samwoo The Variable picker currently is not supported in the new style multi-line text boxes used in some of the business process nodes, that's not to say you can't add variables manually. We will be releasing support for that shortly, so watch out for the updates in the admin tool. As @DeadMeatGF has suggested you can either use a node which uses the original style fields and then cut and paste, or the wiki page contains the values as well so you can copy the format etc and build these up manually until the new multi-line text box support for the variable picker is there. Sneak preview In regards to the use of the Get information node, you can use these at the beginning of the process and this should be available for the variable picker further through the stages nodes. The logic behind allowing you to use it again and again is perhaps more aligned to the Get Request details option, where you might want to ensure that the following human task, to one of these nodes, which uses the 'Owner for Task' variable, is checking who the current owner of the request is, not who the owner of the request was at the point of the original Get information node was called at the beginning of the process. Obviously for custom questions this is static so not going to change, but for request, customer, org type variables you might want to get this / check this before invoking a task etc rather than relying on it still being the same as it was when the request was logged - hopefully that makes sense Steve

Hi @lee mcdermott Do you have this system setting enabled? in the Admin tool under Home > Service Manager > Application Settings This may explain it? Steve

Hi @ljbrown Using email templates you should be able to include most the information from a request using request variables including any data which is held in the custom fields of the request. If you are gathering new starter info in progressive capture custom forms, you can map the answers provided to these questions into the custom fields of the request and then include the custom fields as variables in to an email template, which you can then fire to any email address from within a BPM. So firstly, in the Progressive Capture designer you can map the answers of custom form questions to custom fields as covered here: https://wiki.hornbill.com/index.php/Progressive_Capture_Designer Specially the Mapping Fields from custom forms and within this, Using Custom Questions and Answers in Email Templates & Measures The other option is to write the answers from custom forms, into the description field of a request - but the above is probably more usable, but for information purposes this is covered here. https://wiki.hornbill.com/index.php/Request_Variables Now you can include custom information about the New Start into custom fields, you can create an email template which includes data from standard fields and the data held in custom fields: An example below: Once you have the template you can automate this from a business process to any defined email address like below: Now this would not include the timeline information of the ticket but should include all key information held in default fields, and any information you have mapped from custom questions, or added manually to custom fields Hope this helps Steve

@Mark Simpkins In addition to the Hornbill Webinars there is some wiki content which might help introduce the new staff to the Services > Catalog Items, where the Progressive Capture and Business Processes can be joined together and offered to the subscribed users of a service. https://wiki.hornbill.com/index.php/Request_Catalog There is a nice overview video on the above page which explains both the benefits of using the Request Catalog and also where the configuration for adding or editing existing catalog items is performed. Progressive Capture content is here: https://wiki.hornbill.com/index.php/Progressive_Capture_Workflow Business Process Content is here: https://wiki.hornbill.com/index.php/Service_Manager_Business_Process_Workflow Hope this helps Steve

Hi @Keith Sorry for the time this particular feature has taken to materialise, it was a bit more involved than was first thought, so took longer to complete. I am happy to report that this has been developed and is in the final stages of testing before we are able to include this in a Service Manager update. All being well with testing you should see this in one of our next couple of Service Manager updates..... watch out for the release notes You are right this is on the 90 day list, and is sat on our visible queue of features which are work in progress Steve

Hi @David Calder We would expect to see the HUD progress if the action being performed was designed to mark a checkpoint in a stage, or if the action involved the progression to a subsequent stage in your process, equally if an action resulted in say a status change in the Information section we would expect this to dynamically change and should not require a browser refresh to see this. Could you help and perhaps provide an example of when you are seeing this in a process you are running, and also confirm which browsers you are seeing this behaviour on? Perhaps sharing the BPM definition here would also help us see if we can re-create or pinpoint any issue (you can download the process definition from the admin tool and process designer). Thanks Steve

Hi @David Calder Thanks for your post. There is some info on the Hornbill wiki which details a little more about what operations / wildcard searches are supported when searching for requests using the global search: By way of an example PM*189 would have returned your match PM*18 would have returned PM189, and PM18 (if there was a PM18) https://wiki.hornbill.com/index.php/Global_Search_for_Requests Just an FYI in the next couple of weeks you will also see an extended option in the Global Request Search which will allow you to search the content of the posts and comments from the requests timelines, so watch out for the release notes on the upcoming Service Manager updates. Steve

@nasimg @Lyonel The change has been made and it will be available in the next build of Service Manager, which should be available within the next 2 weeks Steve

Hi @nasimg @Lyonel Nice suggestion thanks. This is only a small thing to tweak so will post back here once it's done Steve

Hi @Prathmesh Patel Just to clarify when you say Customer are you referring to a Contact which you have created under an external organisation, or a Co-Worker, Basic User to which you have added them to a grouping of type Company? In the Request list there are different columns for each of the above: 1. Organisation refers to externally supported organisation and contacts 2. Company usually refers to internally supported group which co-workers / basic users have been attributed too. In my example below i have co-workers who are grouped under the Company - Ares Computer Services, and a Contact who works for Acme who are an external Organisation, and some other co-workers who are not linked to any Company grouping. In the admin tool, if your users are associated to the company grouping under Home > System > Organisational Data > Organisation and a group of Company then you should use the Company column in the request list. Let me know if this helps, and sorry if there is confusion on the terminology used Steve

Hi @lee mcdermott The category is the Activity Category. Task, Scheduled Call etc are the default ones You can add your own categorises (as i have) from here, on the right hand side: The great thing about creating your own categories is you can also set appropriate outcome's per Category, rather than just Done Against each category, you can set your custom outcomes (like in the Business Process Designer), and for each choose a display name, colour indicator and also decide if a comment is mandatory if they choose a specific outcome (note required). The Type of Activity is currently going be Task or Appointment - but a Task could say have a category of BPM Authorisation to indicate it is being an Authorisation if you wanted to split these out. Hope that helps Steve

@lee mcdermott Expanding on what Daniel said above, you can also create custom board views on the activities main view making it easier for members of the groups to see what is assigned to them / their teams should they have missed the notifications. In this view below, i have the Group - IT Suppliers and Contract Admin, i then created a Board with a few dynamic lists, which shows me all activities which are pending, if action is due in the next 60 days, 2 weeks or those which are overdue (based on the Activity Due Dates) The great thing about these Activity boards, is that i can create as many lists as i need, and i can set the conditions against which Activities will automatically appear and be removed. In the example above the Contract notice due in 60 days list will be populated with those activities assigned to my group which also meet the following criteria: Category of Activity = Contract Review Status = Assigned Due Date is between 0 - 60 days from now If (sorry when) anyone in the group completes the activity is will move from an Assigned to a Complete status and will disappear from the list - if nobody did action it in 60 days it would automatically move across to the Overdue List as it would then meet it's defined criteria. Not forgetting the lis, and calendar views which are also available in the Activity options, hopefully this gives you some ideas for creating views for groups Activities alongside the notifications, and right hand side sliding panel for access to group activities. Steve

Hi @chrisnutt We are looking into this option, but i would suggest for the time being the next best option would be to use the Business Process linked to each Catalog Item to define the correct Category - this way you don't need to reply on either the analyst or the customer to make the right choice. There are two options here. 1. If you have a BP specific to each catalog item then you can use the Update Request > Logging Category operation and choose the Category you want it to be assigned to. 2. If you are using a BP which is common across different catalog items then you may need to use the following to get what you need to ensure you are setting the correct logging category. Use the Request Get Info > Request Details option followed by a Decision node, and then define Custom Expressions against the Catalog item name / id as shown below - here you can see i have extended the number of decisions possible by chaining to two decision nodes together using a no match join. This can be a little time consuming to remember you can right click then cut and paste groups of nodes between business processes which will save you having to create it time and again (just change the expression conditions as needed per business process). It can also look a little messy on the BP designer, so you can right click and add a new group, into which you can group all the nodes together, then collapse the group to look like this in the designer Expanded it looks like this: Hopefully this gives you something you can work with for the time being, and we'll post back here with progress on setting these in the catalog item configuration view Thanks Steve

Hi @nasimg In my examples in my Major Incident, Problem and Change Processes i have a number of actions which are performed once the ticket has been resolved - in the example below you will see i am doing the following: * Get Resolution Info * Resolve Linked Requests * Remove from Change Board * Update Change Management Workspace that the Change has been resolved * Add to a Hot Topics Board (let the analysts know that a Change has been deployed - in case we start to receive new Incidents as a result of the Change, which we can then link to this change) * Automate the removal of the Change from the Hot Topics Board after either 72 hours elapsed time or when manual task to do so is complete. In relation to the specific Resolve Linked Requests this is the configuration i have in place for this example: So the following applies: Request Type: I have left this blank, so any request linked to this change (which is not already resolved), will be resolved when this is invoked. I could have chosen to limit this to a specific request type (Incident or Problem) Status: The Linked Requests will be moved into Resolved (could be closed if you prefer) Stop Timers: I have chosen to stop any timers which are running on the linked requests Notify Owner: This is set to Yes, and the type of notification they will receive is controlled by this setting: Email Customer: Yes, this will send an email to the customer of the linked requests Mailbox Name: The Mailbox from which the customer's email will be sent Email Template: The email template to send to the customer's of the linked requests Hopefully this explains how this can be invoked. There are considerations for the linked requests to: The BPM of the linked requests As mentioned earlier in the thread, we can't progress the BPM's of the linked requests through this operation as we simply don't know what stage, state etc the linked requests are in, what tasks, approvals etc are pending or what outcomes / directions to take. As such we leave the BP of the Linked Request as is. One approach you could consider is in your linked request processes, is the use of a task during your investigation stage - with outcomes of: * Issue Resolved - analyst has fixed the issue and they resolve the Incident themselves with appropriate branches to send email resolution email etc * Awaiting Fix - Choosing this option, you could follow this with a Suspend - Wait for Resolution option, once the linked request is resolved, this will cascade down the resolution to the linked request, and because it is in a Wait for Resolution state, this will be met, and the next action after that in the linked BP will be invoked. In this scenario three things can happen: 1. If the Analyst who is working on say the Incident, fixes the issue themselves - they resolve the issue and maybe you have your BP linked to this Incident, send the resolution email to the customer, and this BP controls the stopping of timers etc - and the BP completes as expected 2. The request (again assume Incident) has been marked as 'Awaiting Fix' from the task, and as such moves onto the suggested 'Awaiting Resolution' state - now if the Linked request is resolved, the resolution will be cascaded down to this request, adding the resolution, and it is the Linked request's BP which stops the timers and sends the resolution email to the customer - As the BP is waiting for resolution, when this is cascaded down, the Business Process of the (Incident) will move onto the next BP action in it's BP flow. 3. The request (again assume Incident) is in a state where the above task has not been completed, but has been linked to the Major Incident, Problem, or Change - when the Linked request is then resolved, the resolution will be cascaded down to this request, as well as stop it's timers and send the resolution email to it's customer but the BPM will not be progressed Apologises if this is a little long winded but i hope it helps clarify some of the behaviour and give you somethings to consider, albeit i expect you may other several different use cases or requirements but hopefully this gives food for thought Steve

Thanks @Henrik Brattlie, Manag-E for the suggestion, and @Lyonel, @DeadMeatGFfor the support. No doubt this would be a nice new feature. We just need to prioritise it alongside the other suggestions, but as it already has some support this is certainly going to help push it up the priority list. As it progresses we'll post back here Steve

Hi @yelyah.nodrog The multi-select operations only allow you to apply these to requests with the same following attributes: * They are of the same request type * They have been logged against the same Service If these two conditions are met then the multi-select options will remain available, if not they will be hidden. For the Resolve and Close option there is a 3rd consideration, if you select requests which are Open then the action to resolve will be available, if you choose open / resolve status requests then it won't. (as one is already resolved). You can multi-select resolved requests logged against a service and mass close them as well. There are various reasons for this, some to do with only being able to teams which support the specific service, and multi-select requests raised against different services makes this difficult, equally when resolving a group of requests logged against the same service, and request type - you may have set up filters on the available closure categories, but trying to apply this to requests of different types and services may end up in closure categories being selected, which were not meant to be available. There are also options to use the BPM to resolve / close linked requests and this is discussed further here: We do have a request to disable this logic if you don't require it on your instance, but the work to do this has not started. I hope this helps explain the logic as is, a bit more. Steve

@Paul Trenter yep, we start from the position where 'everyone' can see everything, and you restrict this back by adding subscriptions, if it is only certain groups / users you want to have access to the services. So if you remove the All Contacts then the Service will be available to everyone. See how you get on with that. Could you add a screenshot of where you are adding your new contacts? Thanks Steve

Hi @Rachel Crisp Just to add to @DanielRi comments, this is correct that you can only add the first 10 questions from any custom form used in Pro Cap. it is also possible if appropriate, to split your questions across more than one custom form in Pro Cap, and then add more than 10 questions (answers) to the description field of a request. You can achieve this by as i say moving the questions 10+ from the single custom form and add them to a second custom form in your progressive capture (if this is workable for gathering your request info). With this done, in your supporting business process firstly use the Get Request Info - Request Questions option, and specific the first custom form ID - then as you have add the variables for the 10 questions on the first custom form. After this use the same Get Request Info - Request Questions option, but specify the id of the second custom form. Again reference the question variables 1-10 into the description field, but ensure the Append Text is set to Yes - this will ensure the answers to the questions on the second custom form are appended to the existing answers already added to the description field from the first custom form. Giving you more than 10 answers, albeit from across multiple custom forms. I hope this gives you something to consider if you need to add more than 10 answers to the description field. Alternative approaches include mapping custom questions into their own fields in the details section of the request form, and this is covered here on the wiki in the progressive capture section https://wiki.hornbill.com/index.php/Progressive_Capture_Designer - Mapping Questions from Customised forms. Steve

Hi @Sonali I have just checked and as @lyonel says, if the name (ID) matches then this should be functioning as expected. you can check that Business Process ID from the Manage Process Settings (top right) in the business process designer. One thing you could possibly check, is if in your logging process (using Progressive Capture) if you are using the Services Details form as shown below? If you are, and a Service is being selected, then you may want to check the default Business Process which is invoked if the Problem is logged against a specific service. You will see that the default business processes maybe 'Example Hornbill Problem Process' which may explain why you are seeing the behaviour you are? The logic here is: 1. Check if a Service is associated to the Problem on creation. 2. If a service Exists, check and use the Business Process if it is configured in the Services Request Configuration for the selected Service (as shown above) 3. If no Business Process is configured against the Service, then don't invoke a business process 4. If no Service is associated with the request then use the business process (if set) under the app.requests.defaultBPMProcess.problem app setting. I hope this helps, and i can see this maybe repetitive of some of the advise above, but let us know if you are still having an issue Steve