Steven Boardman

@gwynne Just a progress update in this area, we did release a feature which would allow your manager to be a member of all the teams which they are interested in monitoring, but by using the option in the admin tool, they would not be visible to have requests assigned to them from the assignment options - but they would be members of teams to be able to view all requests. This is in the admin tool, and you can add them to the teams, and then disable the assignment for them per team, as shown below. Steve

Hi @StevePotts Thanks for your post, this is potentially a lot of data you would get out if you ran a query to get all tickets, all posts, and all comments on the posts in the ticket, just being curious (nosy) is there something specifically you are looking to get with this type of report? It is not unusual to run reports on all all requests, by say priority, status, date periods etc but just looking to see if there are other ways to get what you need? Two options which may or may not help are: 1. On the request list, you have the option to export the list to csv, and include the primary information about the request list content (albeit not the timeline info) 2. On each individual request there is a print option which allows you to tailor the level of detail you are interested in regarding the request including the timeline info. Steve

Hi @chrisnutt Thanks for the post and for posing the question. I think there are a couple of things here. 1. The organisation of your services / catalog items into categories for the benefit of your customers via the portals. So here you can group your Services into Service Categories so that on the Portal, a customer can choose to filter their services by say Business Services or People Services (HR), Facilities etc, which makes it easier for a customer to find all the services which are provided by different functions in your business, and then under each Service you can define the options they have when raising requests (Catalog Items) 2. The Category options on the Service form and per request type, whilst they could be seen as being used to apply a specific category for requests raised against the service and that request type, they actually act as a way of filtering which categories (logging and closing) will be visible on requests which are logged against that service. So in the example above, i can limit my closure categories to those which fall under the Projects Branch in my category structure - so that when my analysts are working on a Service Request raised against this particular Service, they can only see and choose from one's which are under the starting point i have specified here. This hopefully makes it cleaner in environments where you have multiple teams (IT, HR, Finance etc) having their own services, and they see no reason why analysts in other functions who do not support their services, seeing category options which are not relevant to them. I hope that makes sense? Finally i think you are referring to an option on the Catalog Item configuration screen which would allow you to apply a category to the request when a request is raised against this Catalog item? As you rightly point out this is not currently available, but you can as you say use the BPM option to Update the Request Category so that the Category is correctly set when the related business process is invoked for each catalog item. We don't have anything currently scheduled to have this option added to the Catalog Item configuration screen but as and when this progresses i will post back here. Just to advise you, if you did not already know - we encourage customers to post these ideas here, so that we can get buy in and support from other Hornbill customers and this helps us prioritise which stories / changes we implement first so please do continue to post ideas and suggestions, and i'm sure you'll see from other posts, other customers contribute and this helps to move those feature requests along Steve

@fisky we have added you to the list of interested parties to the story Martyn references above - this helps us prioritise the stories we are adding and allows us to inform you are these progress Steve

Hi @Paul Trenter Thanks for the post. I have just tried to replicate the issue, and i can't seem to re-create this issue. So just to be clear: You have a Service, which has All Contacts under the Subscriptions? You then add a new contact to an external organisation, and create them a portal account - login details / password etc If you then go the Customer portal, that new contact can't see the services which All Contacts have been subscribed too? I just wanted to check the terminology here, and by All Contacts you are referring to those created here for example, and those that access the portal through customer.hornbill.com/<YourInstanceName> Compared to what is referred to as basic users, or co-workers (internal staff generally) who access the portal through the internally facing portal of service.hornbill.com<YourInstanceName> ? If you could confirm that would be great Steve

@DougA So looking at this, you have the PC which is linked to the Raise New button or other request types in the user app for Analysts - and his asks for customer, request details, service - but this is not the case on the portals - the above mentioned PC is not used at all on the portal, it is just the PC linked to each Catalog item, so as you say, if you want to prompt the Customer for the Request Details you can include this form in the PC's linked to each catalog item. This should not effect the console experience for your analysts as you appear to be using the Switch Process node in your PC, so this will check to see if the form in PC has already been used and if so, it will not repeat it when switching to the PC linked to the catalog item. In my example below: My PC linked to the Raise New Option is this, which is similar to yours I then have a PC linked to a catalog item, which also includes the Request Details form: When my analyst logs a new request and chooses the catalog item and switches to the PC linked to that catalog item, the request details form is skipped and the analyst is taken to the next form, in my case the Scheduling one as shown below My customers on the Portal, when they select the Catalog item will be presented with the Request Details form: Hope that helps Steve

@DougA are you referring to the Progressive Capture forms? so as you say the Customer Search and Services forms are skipped because we know who the logged in user is, and which service and catalog item to raise it against based on the choice they made to get to the Progressive Capture flow. So if that is the case, and you refer to the Request Details, is this not a case of using the Request Details PC Form, to prompt the customer for the summary or description? or a custom form which then maps to the Summary or Description fields once logged? or if the Request Details are always the same (i.e. summary and description), then you could use the Update Request option in the linked Business Process, so this is automatically set when the request is raised and the Business Process is invoked (obviously you could set this differently for each Catalog Item) Sorry if i have misunderstood Steve

@Henrik Brattlie, Manag-E In regards to the operator knowledge capabilities, our next step here is to provide the operator and or the customer some data driven knowledge at the point they are raising requests, and in Hornbill this equates to having knowledge available to you in Progressive Capture. When either a customer or support person is raising a request, knowledge in the form of FAQs, Published Problems and Known Error's etc will be presented as they work through progressive capture, using information from progressive capture to narrow down the search results. For example if a Service is selected, then the available results will be narrowed to knowledge linked to that Service. We are due to start this particular feature shortly, i will update back here once this is in progress.. Steve

Hi @Prathmesh Patel Thanks for your post. It is not possible to change the Request Type of a ticket once it has been logged. The main reason for this, is the supporting business processes which are in flight once a ticket is raised, generally based on the Service, and or Catalog item which have been selected. In addition to this, the business process which is running may have dependancies on the data collected in the Progressive Capture logging experience, and so switching the Request type and therefore the supporting business process would be problematic at various levels (Service Level Timers, Routings, Task allocations etc). What we suggest is the option to create a linked request with the correct type, service, catalog item (where applicable), and close the original one down / or cancel it. Through the use of the Catalog item's under the services, we would hope that this would reduce down the number of incorrectly logged requests in the first place, as the options for the analysts or customers on the portal can be presented in non-technical terms. Alternatively if Catalog Items are not in use, using the Progressive Capture, if configured can allow you to select the 'Request Type' after you have collected all the relevant information from the caller in order again to ensure where possible that this is correctly logged. Steve

Hi @Lyonel No progress as yet i'm afraid. This is not because it is not a good idea, it just needs to be prioritised alongside everything else, and as you can imagine we have lots of great ideas to work through. As soon as it gets to the top, i will post back and keep you informed of it's progress. FYI this is not a big change, and as such we have a 'pot' of smaller quick wins which we work through, in and around the larger changes. It is just currently sat behind a few others. Steve

Hi @DougA You should be able to reorder by dragging and dropping them into the desired order once you have created them from within the the forms designer? Let me know if this is not the case for you, but i have just checked and this seems to be working as expected. Steve

Hi @yelyah.nodrog I think what @DeadMeatGF was saying, is the same as i was trying to suggest (obviously not very well sorry ) You are right there is a single PC which is invoked when your analysts select ' Raise New' so we are not suggesting you need to alter this, until such a time as you are ready to switch from the existing PC to the new one you are trying to create. What is being suggested is you in fact via a test service and a test catalog item to mimic what would happen when your analysts press the 'Raise New' option. So under a custom expression in your existing PC, when you get to the Services form, one of your decisions is to see if the test PC linked to your test catalog item in your test service is selected - if so, switch and use this pc - as @DeadMeatGF says. No one else will see this option as they are not subscribed to the test service nor support it. You can then create all the different PC's which you need for the different catalog item's, and for test purposes simply add them to your test catalog item, under the test service and run them through - once you have done one, switch the PC linked to the test catalog item to the next PC you want to test and so on and so on. This would allow you to validate that each PC for the catalog items are functional, and these can then sit under the catalog items which are in Draft status, until the time you want to promote these to live. This does leave the question of making some changes to the primary PC which is used under the Raise New button, and in order to do this hopefully there are some quick changes (again which you may want to test under a PC linked to your test service / catalog item), but you can use : A decision node after the Services form in the primary PC, which simply checks if an analyst has chosen a Catalog item or not - we don't need to know which one, as we can pass in and just check this using a variable as shown below. in this case checking if Service Details > catalogProgressiveCaptureID Is Set (has a catlog item been chosen) followed by the Switch Process node which is set to: Variable - Service details->catalogProgressiveCaptureId - which will switch to the PC linked to the Catalog Item chosen. Now if you have this off the Service PC Form, there is also the possibility that your analysts may choose the Parent Service, or you may want them to, in which case you would need to add in additional branches and logic to cater for this (as it looks like you currently do), however if you wanted to keep straight forward in your primary PC, and ensure that a Catalog Item is always selected (rather than a parent service), then you can enforce this through the following setting when you are ready: Now with this enabled, you would not need to build in extended branching into the primary PC used on Raise New as the analysts would have to select a catalog item to progress from the Services Form, and moving forward it would make the testing of PC flows easier, as you could as suggested just create a test Service with a Test Catlog Item which only you would see and use this to test all new or revised PC's before switching them on the catalog item themselves, which the default PC would just pick up on through the Switch Process node in your primary PC after the Service Form. I apologises as this is a bit long winded but i hope that helps Steve

@yelyah.nodrog You should just be able to create one test service and use this for any BPM's or PC's which you are using on existing services. The key here is that the test service is a container, and you associate and un-associate the BPM's and PC's you want to test, and you can change these / swap them out going forward. I would not advocate having duplicate test services for each service, as at 20 this is not practical and at 100 even worse. The Service (container) is more or less static, save for the name of catalog items, it is the BPM's and PC's which are fluid and where the testing is really performed. One consideration you may want to bear in mind is excluding any test requests which are logged against this test service when it comes to reporting. you could just add an exclusion in your reports to not show requests logged against your test service. Steve

Hi @DougA Just to reassure you, all posts in the forum are read and we like to post back when we have a response which is progressive (positive or negative), we'd hate for you or anyone else not to post, and please don't take no comments as an indication that it isn't being considered / reviewed, even if it is something which we can't immediately action. All feedback is appreciated and it is noted that an acknowledgement comment from us, would help to communicate that it has been read Steve

Hi @yelyah.nodrog An approach we recommend for testing your business processes and progressive captures is to create a test service - you can then create copies of your live BPM's and PC's and link these to your test service / catalog items. If you subscribe yourself to the service as a customer, and only you support that service (supporting teams) then no one else on your instance will be aware that this service exists, and you will be able to make changes to the copied BPM's and PC's for testing purposes and run these against the test service. Once you are happy with the changes you have made to your BPM's / PC's you can use the download option for their definitions, and upload these to your live BPM's and PC's to have them take effect going forward. Once downloaded you can go into the 'live' version and then use the upload option to apply the updated version of the process Hope this helps Steve

Hi @Graeme Clark Yes you would need the rule for the live.hornbill.com set-up, as you have done this and you are still not seeing the emails, i think the best course of action is to get this logged as an issue and we can take a look for you - if you could raise the issue here, we can do that for you. https://www.hornbill.com/request/ Thanks Steve

@Tina.Lapere We have added the option to the admin tool, so you can in one action, add all your users to this role - see option below. Steve

@nasimg In regards to the question on the non sending of the resolution emails, as @Chaz highlights this is likely because this feature will not progress the Business Processes of the requests which you are on mass resolving. There are many good reasons not to do this, but one primary reason, is because we can't know where they sit in their processes, what needs to happen next etc. Is it a human tasks with multiple outcomes, is it suspend wait for category, priority etc again we can't guess any of this, as we don't know what has been build into branches which follow them. As you say requests will be marked as resolved when using this functions and any timers which are running will be stopped - in order to ensure your Service Level reports are correct. There are a few options here. 1. If requests are in a 'suspend await resolution' state, then on the multi-select and resolving, the processes will continue and any resolution emails which are mean't to be sent after resolution will be sent and the processes will continue. 2. Instead of using the 'multi-select' option on the request list, if you opt to use the Business Process operation to do the same thing - by building this into your Major Incident, Problem or Change processes, then you can ensure a resolution email is sent to the customers of the child Incidents, or other requests by choosing this attribute when configuring the BP node. So on resolving the parent ticket, the linked tickets will be resolved, timers stopped, owners notified and customers informed. 3. A variant of the above, but if requests are in a 'suspend awaiting resolution' state when they are linked to a parent ticket, then on the resolution of the parent ticket, they would be marked as resolved, and if they have a resolution email option configured in their business processes, after they are resolved, then their business processes would take care of sending the resolution emails rather than from the parent. As this is new functionality is new, it will take a little adjusting to and possibly some re-jigging of business processes to fully utilise the, but i hope you agree these are great features compared with having to do this manually on each ticket. As @Chaz also said we are happy to take feedback and enhance this where we can. Steve

Hi @DougA I just want to be sure i am looking in the right area - you are talking about configuring the say Incident form, under a specific service? Here i have added a custom field, and changed the label to 'Test' and it has saved the new field name, and in the translations tab added the default English (British) version for me. Can i also confirm when you are in the designer that you hit the 'apply' on the form shown above, and then the 'Apply Changes' button for these changes to be saved? Thanks Steve

Hi @DougA All customer feedback is reviewed and discussed, as you can imagine we get lots of great ideas and it is a case of working through these and setting some form of prioritisation with these. One way we do this is to record the number of customer's who have expressed similar requests, or supported ideas which have been raised, that said this is not the only mechanism we use for helping us work out what great features / enhancements we are going to work on next. On this we also try to look at what is being asked for, and what problem we are looking to solve, and sometimes we come up with different approach than is originally suggested. One example of this could be that a number of customers use the expire options on tasks etc, in the absence of a more elegant way to handle two stage closures, and the variables of customer's reopening them etc, we have a story which will be started soon which will provide a solution to this - in fact i think Gill Lee was one of the customers who requested this. On your specific example, as soon as there is progress i will of course post back and update forum. Steve

@yelyah.nodrog @Lyonel and @DeadMeatGF are correct the way to do this is through the business processes which are supporting your catalog item options. Now there are a few things which may influence the best way to do this. 1. If your existing Service/s, have been set up with multiple Catalog Item options (to reflect the types of issues / category of issues customers can log) as per the example below - Then you could add an additional Catalog Item for the new type of request (category) you wish to offer, and then against the Catalog Item add a Business Process, which routes the requests raised against this specific catalog item to the required resolver team and with the required priority pre-set. 2. If however you just have a single Catalog item defined against your service/s, something like the below then you would need to add logic into the supporting business process of that catalog item to check what the logging category was and branch and route to the different resolver teams based on that. This is assuming you prompt your customers to provide a category during the progressive capture process. In option 2 , in your single business process, you may need to use the Get Request Information > Request Details option and then a decision node, followed by a couple of custom expressions to check the Logging Category, and branch to different assignment node based on the outcome. In the different paths you could set up the assignment nodes, and the Update Priority based on the category. With option 1 described above you would not need to do this, as you can link a specific business process to each catalog item (category in effect) and in that specific business process, you can just define which team to route it to, and which priority to set, if the customer chooses that specific catalog item from the portal. Hope that helps Steve

@Prathmesh Patel Just an FYI - we have a new feature coming out in the next 2/3 weeks which will allow you to automatically change the Status of the services from within any Business Process, using the Business Process Engine. So if you imagine you identify a Problem, you could build into your BPM the option to automatically update the Status of the affected Service (so customers and analysts can see this), and then once the Problem is fixed / closed you can automatically change the status back to either Available or no Status at all. Currently you would need to do this manually through the Services View as shown above, but as i say there will be a option to automate this in the coming weeks Steve

Hi @Prathmesh Patel Would you be able to expand on what you are looking for with the status page? The data returned to each customer on the customer or service portal is dynamic based on what services they are subscribed too. In the case of the Status of the services which the customer is subscribed too, if any of these are set to say Impacted or Degraded then there will be an Impacted navigation option visible. In addition you can create bulletins from within each Service which can broadcast news and information to the subscribers of the service, and will appear in the carousel on the services view, and also on each services page. As mentioned the above is derived from the configuration options on the various services which the logged in user is subscribed too. Hope that helps Steve

Hi @Graeme Clark Currently Some of the email notifications need to use a form of direct messaging due to an issue with mailbox rights, as such you would need to ensure you have routing rule configured in your Outbound Routing Rules as mentioned in this post below - this might be a good starting place for investigation. Steve

Hi @Graeme Clark Currently Some of the email notifications need to use a form of direct messaging due to an issue with mailbox rights, as such you would need to ensure you have routing rule configured in your Outbound Routing Rules as mentioned in this post below - this might be a good starting place for investigation. Steve