Hornbill Staff DR

Hi Dan, I've encountered the need to set a "due date" on several occasions during my work with customers. Essentially the need to set a target based on a specific event that is influencing the delivery of the work (e.g. end of the financial year, an audit deadline, or a new member of staff starting) - which is what I would understand as being "fluid" in your description i.e. the due date could be quite a strict deadline (unlikely to move) but the factor influencing the deadline can variable for each piece of work. The immediate benefit of such a feature would allow easy sorting of the request list but in terms of the performance and service delivery improvement I'd be interested to know what type of reports or metrics would be useful to you in relation to a "due date". At the very least I would expect there is a need to compare the time at which the request was "marked" with the due date target, and then set a 1 or 0 accordingly - representing whether this was marked within the due date, or exceeded the due date. Would you be able to elaborate further in this area, or is the need essentially the same as reporting on Service-Level-based targets? I'd also speculate that there should be restrictions when it comes to editing any existing due date on a request. Who is involved in managing and setting of due dates in your scenario? The concept of a due date is already under discussion by the Product team and I understand you may already have contributed in some conversations but it would be great to hear a few thoughts on the latter points RE: reporting and governance around amending a due date. Thanks, Dan

Hi Steffen, I've added the BPM definitions for you to explore at your leisure. These are based on the "EXAMPLE Hornbill Service Request Process" which is shipped out-of-the box. The first definition below utilises two human tasks:  example-hornbill-service-request-process-incorporating-manual-authorisation.bpm.txt This second definition ("v2") replaces the first human activity with a BPM email notification which automatically looks up the line manager of the customer. This second approach is dependent on user-manager relationships existing in your instance. example-hornbill-service-request-process-incorporating-manual-authorisation-v2.bpm.txt I hope that helps, Dan

Hi Steffen,  to add to Stevens description above, here's how that would be achieved:  If Line Manager information is being stored against a user (typically populated through the user import) there is scope to replace the first human task with an automated email to the line manager as follows: Of course you can adjust the "on-Hold" behaviour to suit your particular scenario(s) too. Dan ÂÂ

Hi Alisha,  thanks for your post. The logs can be found in Hornbill Administration via Home > System > Monitor > Monitor Log Files and this error will be logged in EspServerService.log The logs are only accessible by someone with the "Admin Role" security role and typically only show the activity for the current day (as they're archived when they reach a certain size). If you don't have permission to access the logs I would advise speaking with the person responsible for administering Hornbill as they will be the ones who have the access. Once you've found the error, please post it here and we will be able to offer further assistance. I hope that helps, Dan

@Jeremy I think I understand what you're saying. I assume the progressive capture question is using a select box being driven by either a static list (configured in the pro cap field) or a dynamic list (located in Service Manager simple lists). Is that right? So you're suggesting that the decision was once using the "value" in its evaluation but now is using the "display name" in the evaluation and therefore failing to match the string "Windows 10"? Can you send a screen shot of the simple list or static list you're using and confirm my interpretation above? Thanks Dan

@Jack_Podmore thanks for posting! As @HHH has said, these button labels can be changed by amending the appropriate translation string in Hornbill Administration > Home > Hornbill Service Manager > Translations . Every piece of text throughout the application has a translation string and as well as allowing us to display the term in German, French, etc we can also amend the English translation to use more appropriate terminology. When it comes to the portals, the strings you need will depend on what portal you're working with. As you might know, Hornbill Service Manager has two portals. The "Customer" portal facilitates external support and is used in conjunction with contacts whereas the "Service" portal is used to deliver a support function within your organisation and is accessed by Basic Users. Each portal has it's own set of translation strings: For the Customer portal, all translation strings begin with    guest.com.hornbill.servicemanager.portals.portal....... For the Service portal, all translations begin with    guest.com.hornbill.servicemanager.portals.servicePortal........ A very subtle difference, but one to be aware of. Therefore I believe the translation strings you're looking for are:    guest.com.hornbill.servicemanager.portals.servicePortal.home.requestView.details.resolve.working and guest.com.hornbill.servicemanager.portals.servicePortal.home.requestView.details.resolve.broken I hope that helps! Dan

@samwoo I think I may be able to offer some advice in relation to the errors you posted above: https://eurapi.hornbill.com//xmlmc//apps/com.hornbill.servicemanager/?method=shrGetCustomerDetails: invalid request :path "//xmlmc//apps/com.hornbill.servicemanager/?method=shrGetCustomerDetails" . When you see an error stating "invalid request path", this will be most likely due to an incorrect or missing instance name in the conf.json file. I would expect to see your instance name somewhere in the path as follows: https://eurapi.hornbill.com/<instanceName>/xmlmc//apps/com.hornbill.servicemanager/?method=shrGetCustomerDetails .  The reason why it goes onto say "Create" even though you know the asset exists in Hornbill is because the utility could not complete the search in Hornbill due to the invalid path. Basically, the utility did not receive any results from the search to confirm that the asset already existed, therefore it assumed it needed to create a record. This can be seen here: "API Call failed when searching instance for existing Asset:Post https://eurapi.hornbill.com//xmlmc//data/?method=entityBrowseRecords: invalid request :path "//xmlmc//data/?method=entityBrowseRecords"" Specifying a valid instance name and API key in the conf file should address these particular errors. I hope that helps. Dan

Hi @lokent having reviewed the above thread, I suspect the reason for the behaviour you're encountering is due to the user having multiple sessions. By default, a Hornbill instance will permit a single user to login multiple times, be it from the same machine or from different machines and each login creates a session. As you know, when you close a browser, this action itself doesn't kill a session so it's entirely possible to be opening and closing windows all day at at some point multiple sessions may be established. At the end of the day, you log out and close the browser which only closes one of the sessions. All the active sessions in the system can be viewed in Hornbill administration > Home > System > Monitor > Sessions and it's possible to clear any particular session from this view (see image): In terms of preventing multiple sessions from existing, you can change the setting communications.multiLoginUser to to "kick", this means that a user will only be able to have a single session active at any one time. If they login again and another session is created, the previous one will be killed. The setting can be found in Home > System > Settings > Advanced Please let me know if my suggestion regarding the multiple sessions is true, and also it would be great to know if changing the multi-Login setting to "kick" sees a reduction in this situation. Best Regards, Dan

Hi @Jeremy for maximum visibility, reporting would be the best approach here. As Daniel has pointed out, the visibility model for tasks is very much focused around the task owner and task assignee. Lets start by looking at a simple widget to show who has been completing tasks. This requires the Advanced Analytics module found in Hornbill Administration and we can utilise a chart style widget returning data via the "SQL Group By" data type. The data source would be something like below: The configuration above is very general and would return tasks completed by all users, including an "N/A" column as we're looking at all tasks. We haven't yet filtered on status (Assigned, completed, etc.). To ensure you're just focusing on completed tasks, add the filter: h_state = 4 and this will get rid of the "N/A" results. Setting the date column to "h_completed_on" allows us to begin looking at the data over certain time periods, for this to take effect it's necessary to select the desired "Sample Period" in the field that immediately follows. If you're interested only in the tasks completed by users that belong to a particular team (or other Hornbill group), it will be necessary to enhance the filter. The following will acheive this: h_state = 4 AND h_completed_by IN (select h_sys_account_groups.h_user_id from h_sys_account_groups WHERE h_sys_account_groups.h_group_id = "MYCOMPANY/IT/SERDSK/") Replace "MYCOMPANY/IT/SERDSK/" with the ID of the group that you're interested in. This can be obtained from your organisation structure. If you're keen to understand the other task status values, these are as follows (taken from https://api.hornbill.com/docs/_types/taskStateType ): <xs:enumeration value="assigned" esp:mappedValue="1"/> <xs:enumeration value="accepted" esp:mappedValue="2"/> <xs:enumeration value="complete" esp:mappedValue="4"/> <xs:enumeration value="rejected" esp:mappedValue="5"/> <xs:enumeration value="cancelled" esp:mappedValue="10"/> <xs:enumeration value="expired" esp:mappedValue="16"/> I hope that helps, let me know if you need some help with other task-related reporting requirements! The application entity viewer that may help with the identification of columns when building more metrics and reports: https://wiki.hornbill.com/index.php/Application_Entity_Viewer Dan

To expand a little more on progressive capture custom forms, if you have a key piece of information being captured by custom questions, it may be prudent to use field mapping to ensure the data is stored in a more accessible way. Field mapping (https://wiki.hornbill.com/index.php/Mapping_Fields_from_Customised_Forms), allows us to map the information being captured via custom forms to a column in the main request table, h_itsm_requests. The benefits are as follows: the data will exist alongside all the standard request data allowing you to focus on a single table in your report. the data can be mapped to a field of an appropriate type i.e. when capturing date-time stamps this can be mapped to a field that specifically expects a date-time stamp. If we were to apply field mapping to the above example, so the booking date being captured is mapped to a specific date-time field (say h_itsm_requests.h_custom_21) we could use the Advanced Analytics module to build a measure to show when the bookings were requested. In this example, setting h_custom_21 as the "Date Ranging Column" would enable daily, weekly, or even monthly trends to be captured.  Once we're capturing the information in a measure, this would mean we can use the other chart widget data-types such as "Measured Samples", "Measure Group By", and "Measured Samples Group By". Of course, a measure would only be useful when looking at past data. Dan

Hi Lauren,  thanks for your post. When it comes to information gathered using custom forms/fields during progressive capture (which are ultimately displayed in the "Questions" section of a request), this information is stored in a table called "h_itsm_questions". The attached image shows the table description that can be found in the entity viewer (https://wiki.hornbill.com/index.php/Application_Entity_Viewer) - a very useful tool when it comes to building reports or measures. I'll start with a rather crude approach which looks directly at h_itsm_questions, and aim for a count of records grouped by date i.e. the number of bookings for each unique date found in the database. In this case, I'm assuming that you've got a date picker in your progressive capture which will lead to a date/time stamp (YYYY-mm-dd 00:00:00) being stored in the database. If you're using a date/time picker, then this approach won't work and we'll have to go into more detail. Either way, the date-time stamp will be found in the column h_answer. To isolate this information, it will be necessary to focus on this specific question. You can use "h_question_id" or "h_question" to do this. "h_question_id" will contain the field id of the field in progressive capture, "h_question" will contain the label that you specified for the custom field:  In terms of the method we use to get the information out of this table, assuming we just want to focus purely on this piece of data we could utilise a Chart Widget using the "SQL Group By" data type and set the data source as shown. As I said, It's quite a crude method and I have made an assumption about how the progressive capture is set up and thus how the data is stored. If you're using a date-time control rather than a date control then that means there's going to be many unique timestamps and this method won't be suitable .  Let me know if that helps at all, I've got some alternatives which I will follow up with shortly. Dan

Hi @Dan Munns while the enhancement was accepted and a development story now exists for this, this particular story doesn't currently sit in the 90 day outlook. I've ensured you have been added as a connection and I will look to highlight this as a candidate for progression, however this will of course be reviewed in conjunction with the other development stories put forward. Naturally, at this stage I'm unable to provide an indication of when this may be delivered and I'm sorry I can't provide a more constructive answer at this time. Thanks, Dan

Hi Sam,  thanks for your post. I'd be interested to know a little bit more about the way you're operating. As you're probably aware, the concept of "Ownership" is one of the core principles of the Hornbill Platform and exists in all the apps that you might install. Many of the objects across the apps are subject to an owner, such as documents, activities, and of course requests. This is intentional and aims to help an ethos of responsibility. While you raise an interesting suggestion regarding the "reopen" button, my first question would be, why is the request passed back to a holding queue once its been resolved? Why wouldn't the resolving team maintain ownership through to closure? The closure of the ticket is when we can be confident that the request has been dealt with. If its a question of removing the request from the teams field of view, resolved requests can be filtered out. To broaden the scope of my response and talk a little more generally, have you got metrics in place to understand how frequently requests get reopened and to capture the reasons why this is happening? Are agents being too overzealous in resolving requests without proper consideration for the customers needs. Are customers tagging on new issues to an existing request? Typically, the best solution to this challenge begins much further upstream. Dan

I'm glad you found it useful @lokent ! In terms of instance storage, there is no specific allocation for email messages that exist in the mailboxes but the messages will contribute to the overall space consumed i.e. the contents of the mailbox folders can grow and grow until you reach the storage capacity of your instance. If you want to see details of the available storage, it can be found in a tab located in the Hornbill App Store: Home > App Store then click on "Subscription" which will show the following:  More information on your instance storage quota can be found here: https://wiki.hornbill.com/index.php/Instance_Storage_Quota Dan

Hi Lauren,  further to @Pamelas post, Hornbill Administration provides an overview of the current content of each of the folders within a Hornbill Shared Mailbox. This can be found via Home > System > Email > Shared Mailboxes and then click on the mailbox of interest (in this example mine is called "Helpdesk") followed by the "Status" tab.   The total space being consumed by the current contents of the Shared Mailbox can be seen in the bottom left hand corner with a per-folder breakdown shown in the "Folder Size" column. As Pamela says, you can delete the actual email but any timeline text will remain in the request. I hope that helps, Dan ÂÂ

Hi Daniel,  thanks for your post. Both requests and asset records support the adding of attachments. Whether the user is required to sign an electronic document of some kind or you simply require their signature as a image, I'm sure this can be emailed back to the service desk upon delivery of the new asset to the customer. Naturally, I would assume there will be some prompt or checklist within your business process to ensure the technician completes this step prior to closing the request. Whether the attachment ultimately resides against the asset record or against the request itself would largely depend on your preference and what you feel makes sense based on what the signature represents. You mention that it would indicate receipt of the device and acceptance of the usage guidelines, thus in my opinion linking this information to the request would seem logical as this is more about the procurement and delivery of the asset (performed as part of the request) and acceptance of broader IT policy, rather than anything really specific in terms of Asset no. XYZ123. It would be good practice to ensure the request (and any subsequent requests relating to reallocation of the asset) is linked to the asset record. I hope that helps, Dan

Hi @Johanna Guest  thanks for your post. I can see development indicated to you that they have managed to identify and address the issue in time to be incorporated into the next build of Customer Manager. I'm told that this will be made available on Tuesday next week at which time an update will become available for you to apply via Hornbill Administration. I hope that helps set a little more expectation in terms of when the fix will be made available. Dan ÂÂ

Hi Dan,  I've been reading through your post and I'd be curious to see the BPM that you have in play. From what I can tell you are unable to evaluate effectively on the display because this will only be either "Review" or "Query". The "value" is holding more granular information (Query [hours], and Review [hours], etc.) I'm curious why evaluating directly on the progressive capture answer (rather than using the custom field in the request) is not suitable? It would be good to understand the challenge further. Thanks, Dan

Hi Darren,  thanks for your post. Looking at the API's available I would expect that if all you require is a single contract adding to each organisation this would only be a couple of hours work. We would simply need a spreadsheet containing the following information for each contract:   orgId xs:integer required once Organisation ID name xs:string optional Name of the Contract description xs:string optional Description of the Contract dateFrom xs:dateTime optional Date the contract starts dateTo xs:dateTime optional Date the contract ends value xs:decimal optional Value for the Contract contractType xs:string optional The type of contract. Stores the key from a Profile 'cm-contract-types'  We would then prepare an API sequence by looping through the rows and add each contract. Of course, if there were subsequent elements required such as contacts associating to contracts this would need further consideration and will of course increase the time required. If you would like a formal estimate and Statement of works preparing, please don't hesitate to get in touch with your specific requirements via the Hornbill Success Portal: https://success.hornbill.com/hornbill/ and we would be more than happy to discuss further. Dan ÂÂ

Hi Helen,  thanks for your post. It is possible to have a different progressive capture experience when initiating the raising of a linked request via "Raise New Linked Request" compared to the progressive capture that is initiated by clicking the arrow and selecting a particular call class such as "incident". This button (and each of the call class buttons in the menu) have progressive capture flows anchored to them via application settings. So I would start by understanding which of your progressive capture flows are initiated in each scenario. The application settings can be found in Home > Service Manager > Settings and filter on: app.itsm.progressiveCapture . The image shows which application strings are associated with each button/menu item. Once you have identified the progressive capture flows involved, we must establish how the summary is being populated. There are three ways of capturing information to put in a request summary: 1. Using the standard "Request Details" progressive capture form 2. By using field mapping within a purple progressive capture custom form 3. By using the relevant automated operation in the BPM (Methods 1. and 2. capture the summary information during call logging in progressive capture. Method 3. populates the summary retrospectively once the request record exists in the database) Are you able to identify which capture flow gets used when you click the arrow then incident? This will be held in the application setting app.itsm.progressiveCapture.newIncident . Does the Request details form exist in this particular capture flow, or capturing the summary via field mapping? Dan

@davidrb84 the Knowledge centre doesn't discriminate between the request classes. CH's, PB's, IN's etc are all returned if they're deemed relevant (see the image attached.) In terms of the PB/KE divorce you speak of, this simply allows more flexibility in the way you use Hornbill within your organisation. It allows you to be selective in terms of the Problem Management elements you use and also means that you could potentially re-purpose these call classes if you didn't wan't to utilise them in a strict ITIL Problem Management context. Dan ÂÂ

Hi David,  thanks for your post. The latest build of Service Manager incorporates a new feature called the "Knowledge Centre". When enabled, the feature returns relevant Requests, FAQ's, and Known Issues based on the words being typed in the "Summary" field when logging a call via progressive capture. More information on this new feature can be found here: https://wiki.hornbill.com/index.php/Knowledge_Centre I hope that helps, Dan

Hi Chris,  it won't be strictly related to when the ticket was logged, but that can be a good reference. It's more about the time when the BPM tried to perform the operation that failed. Therefore, if the BPM operation took place prior to the fix being applied, then the BPM will fail. If the BPM can be successfully restarted, then that indicates that the underlying cause has been addressed. If you are still experiencing problems with more recent Change requests, this may indicate an issue is still in existence. I hope that helps, Dan

HI Gareth,  email notifications concerning call logging and call closure would indeed be configured in the BPM and by the sounds of it you've updated/included the relevant nodes in your BPM to contain the name of the template you now want to be sent. If its still sending the old one, have you published this new version of your BPM? Publishing is necessary in order to make any changes you have made active. The video below is taken from the following wiki page and describes the BPM publishing feature in more detail: https://wiki.hornbill.com/index.php/Business_Process_Designer   Let me know if this helps, a screen shot of your email notification node may assist with some further context if publishing turns out not to be the issue. Dan

Hi Lauren,  My previous advice would not apply to this message you have now reported ("The flow is poorly formed - loop detected...") and it sheds new light on your situation. There are underlying checks in the progressive capture flow switch-capture mechanism that protects against a flow referencing itself and creating a loop. It may not be literally referencing itself during the switch, but I suspect that if the configurations of two flows are very similar then maybe the system is interpreting it as a possible loop. Perhaps this mechanism is being over cautious in its evaluation, in which case we may have to seek developer assistance in order to "tune" this for a future product build. Anyway, before we get to that stage it will be necessary for me to understand the way you have your progressive capture flows set up. As your organisation has purchased a Success Plan, and we are going to require more detailed specifics in relation to your configuration, I'd recommend that we move this investigation into an incident logged with support. I can see that you have already reached out to us via email however we are still waiting on confirmation of your supported contacts that we hold on record before we can raise an incident in your name. For the time being, I will raise the incident in the name of one of the other supported contacts we have on record and someone will be in touch later this afternoon. Thanks, Dan