Jump to content


Hornbill Product Specialists
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by DanielRi

  1. Hi IT Specialist, thanks for your post. Hornbill User accounts are archived by setting the user "Status" to a value of "Archived". User accounts with a status of "Archived" will not shown in any user search or other user-related lists or menus. Changing the status of an individual user account The status of a Hornbill user account can be changed via Hornbill Administration > System > Users & Guest Access > Users. Find the account in question and click to view the details. The status field can be found in the location shown: The desired value can be selected from the drop down menu. Using an LDAP Import Configuration to update the status of a Hornbill User Account If you are importing and managing your Hornbill User Accounts based on the contents of your active directory, its possible to update the Hornbill User Account status via an LDAP import configuration. It will be necessary to create a new LDAP Import configuration specifically for this purpose. This is done in Hornbill Administration > System > Data > Data Import Configurations The documentation relating to LDAP import configurations can be found here: https://wiki.hornbill.com/index.php?title=LDAP_User_Import The key information which should be considered is: It will be necessary to define a DSN and LDAP filter query to identify the user objects which must have their corresponding Hornbill user account status set to "Archived". In the User Options tab, the "Status" should be enabled ("Update Only" is typical but this will depend on what other LDAP imports are operating). The value should be set to "Archived". All other User Options can be set to "No Action". I'd suggest taking time to digest the LDAP Import wiki page, particularly the "Testing Overview" section. Should you prefer, if your organisation has a Success Plan you may have available credits which you could could draw upon and have one-to-one guidance from a Product Specialist. Alternatively, Hornbill Expert Services could also be procured. I hope that helps, Dan
  2. Hi @samwoo, glad to hear that's resolved it! I'll feed our thoughts back to the Product Team to see if the options can be adjusted to make the requirement for a "From Status" more obvious. Dan
  3. Hi Samuel, thanks for your post. Whenever I use the suspend wait for status change node I always set a "From Status". This is something I've always done but I do acknowledge that the "From Status" is not mandatory, maybe that's a question for the Product Team. Have you tried setting this? Looking at your design, I assume that at the point it suspends the request will be have a status of "open" in which case this is what you should specify as your "From Status". On a side note, I assume the status of the request is a relevant factor in your process design? If you're just waiting for an expiry time there is a specific node for that called "Await Expiry". I hope that helps, Dan
  4. Hi @RobW thanks for posting. Hornbill Business Process features user-related operations, on of which can Archive a Hornbill user account. An archived user doesn't consume a subscription so in essence setting a Hornbill user account to a state of "Archived" will release the Hornbill Subscription automatically. The operation I'm talking about can be found in a typical Hornbill Automation node as follows: The "User ID" would be the Hornbill User ID of the leaver and could be fed from a variable. The exact variable will depend on where the leaver information is stored against the request or if it was captured in a progressive capture form when logging the leaver request. This is one operation that I've previously advised and worked with customers to implement. With the Hornbill ITOM module it's also possible to manage AD user objects and AD groups through the Windows Account Management Packages available with Hornbill ITOM https://wiki.hornbill.com/index.php?title=ITOM_Package_Library I hope the Archive Hornbill User account operation can offer some value but there's definitely opportunity for further automation in a leaver process. Thanks Dan
  5. @Josh Bridgens great, I think this should be enough for development to go on so I'll leave it in @ArmandoDM 's capable hands! Dan
  6. thanks @Josh Bridgens that's useful info, I've just removed the attachment for security reasons, just in case it contains anything sensitive. Based on the console error it looks like something around FAQ's. Dan
  7. @Josh Bridgens please could you also confirm what self-service interface your users access? We can identify this if you can provide the URL. Thanks, Dan
  8. Hi @Josh Bridgens can I ask you to inspect the browser console when you click into the service. Depending on the root of the problem, something may be shown here in the form of a red error. The browser console can be opened by pressing F12, and then click on the tab labelled "console". Once you've selected this proceed to click the service in My Services (which should take you to your available catalog items) and see if anything appears. The image shows how this appears in Chrome but other browsers have a slightly different interface, however the principle is still the same. Thanks, Dan
  9. Hi @Stephen.whittle, thanks for your post. I've had a look into this requirement and it isn't possible to get the output you need. To achieve this, the measure interface would need to allow us to obtain the average of a calculated value because the age of a request isn't something that's stored in the database. Storing such a value wouldn't be the done thing as age is a situation that changes as time passes and would be obtained by calculating the difference between the date the request was logged and now (the time that the report was run or the measure was sampled). If you're exporting data out of Hornbill you can use the following query to get what you need: SELECT ROUND(AVG(DATEDIFF(NOW(), h_itsm_requests.h_datelogged)),1) AS Average_Days_Open FROM h_itsm_requests WHERE h_status NOT IN("status.resolved", "status.closed", "status.cancelled") You can add criteria to the WHERE clause to get the average age of whatever set of requests you're interested in. The ROUND function is simply there to ensure the result is to a reasonable number of decimal places. What we CAN achieve through a measure in Hornbill is a count of requests that are older than a certain number of days. Not exactly what you want but could be used to give an indication of improvement if the number of requests older than a certain number of months was decreasing. I'd set this number of months to the threshold that is unacceptable i.e. if you believe that the current state of your Service Delivery operations should mean that there should be no requests older than 3 months, then lets count how many requests are older than three months. The target would be to reduce the number of requests older than three months down to zero (or as close to zero as possible). Now, I'm not saying this is a perfect substitute for monitoring the average age and therefore I've fed back the requirement to the Product Owner. While COUNTS are quite rudimentary, they still offer value in that they still allow you see some change and thus contribute to monitoring whether a situation is improving or not. So, to create a measure that will sample the "No. of tickets older than 90 days" would be as follows: Here's the WHERE clause for this COUNT: h_datelogged < DATE_SUB(CURDATE(), INTERVAL 90 DAY) AND h_status NOT IN ('status.resolved', 'status.closed', 'status.cancelled') Other points to note are that the date ranging columns are empty, and I've specified some saved data columns. The reason the date ranges are empty is because for the purposes of this measure we don't want to group the request records by any date value. i.e. it doesn't matter when the request was logged or resolved or closed. What we want is a snapshot of the number of active requests that are older than 90 days. I use the word "snapshot" because this situation will only be true at the point the sample is taken. It's worth noting that this configuration of measure can't be sampled retrospectively in that you can't go back and determine how many requests were older than 90 days at this time last month because the sample is taking a picture of what the data looks like at that point in time. You'll notice that when you resample this measure for the first time, all the samples will be the same, I recommend setting the sample history to 1 the first time you do this. Once it's sampled, increase the sample history to a more appropriate amount and then let sample data build up naturally as per the frequency you're set (daily/weekly/monthly/whatever). The saved data columns are useful when putting this measure in a widget as they'll show how many request are older than 90 days for each priority, team, or whatever saved data column you add. I'd use a chart-type widget set with a data type of "measure Samples group by". I hope that helps, I appreciate that it's probably not exactly what you were after but may go someway to supporting the insight you're trying to gain into your requests. Dan
  10. Hi All, since I posted my original explanation above (which included details on how to join the table h_cmdb_links with h_cmdb_assets using a SQL CONCAT function) there has been a change to h_cmdb_assets to include a column to hold the asset URN. This is called h_asset_urn. This makes writing the above report much easier in that we can just select the columns from each table, without needing to use the CONCAT function in the custom criteria box. The better configuration is shown below: Thanks, Dan
  11. Hi Martyn, thanks for the clarification. The product team are now aware of this requirement so I'll leave it in their capable hands to determine how this addition may manifest itself. Dan
  12. Hi @Martyn Houghton, thanks for your post. Did you have a specific filter in mind, such as the quick filter where you can type to filter the list, or more stock filter options to filter on service, status, etc? Dan
  13. @Gary@ADL thanks for confirming the situation with the expiry date. I'll leave it up to support and the Product team to determine whether the task should allow an expiry date in the past or identify why the bpm doesn't just progress in this situation. Something doesn't seem quite right to me there. In terms of what you can do in the mean-time to make the process more robust, I'd perhaps add some logic immediately before your task to check whether the leave date is before "now" ("now" effectively being the date at which the task is created). I've mocked up an example that will hopefully illustrate how this can be done: The above configuration should allow you to avoid the stuck task where the leave date is in the past. I hope that helps, Dan
  14. Hi @Gary@ADL From your screen shot above showing the variable being used to set the task expiry, it appears you are feeding the task expiry date from a previous task. I believe this to be the case because the variable begins with "&[functions(getTaskAnswers..."). I can see you've given the field an id of "h_custom_b" (so I can see why you might be expecting the value to exist in h_itsm_requests.h_custom_b) however custom task fields don't support field mapping, which is why the value isn't appearing in h_itsm_requests.h_custom_b. You'll be able to find this in h_sys_tasks.h_answers. Just like the request table, the task table is going to contain alot of records. To make life easier it'll be better for us to know the task id then we can query that table and inspect the values captured against the task. Finding the task id is relatively simple. First go into the request and find your task on the right hand side and click on the task title to open the popup. Then, click on the task title which appears in the popup itself. A new tab will open at the main "activities" view (the view where you can see and manage all your tasks). The task id can be seen and copied from the URL. We can then use this in a database query to inspect the data against that task. The following query can be used to get the task record with the columns of interest: SELECT h_task_id, h_created_on, h_answers FROM h_sys_tasks WHERE h_task_id = "TSKxxxxxxxxx" Inspecting the task record will allow you to confirm the situation @Steve Giller describes where the expiry date is earlier than the task created date. If we find that to be true, there's two things that stand out for me: 1) Should the system allow a task to be created where the expiry date is earlier than the date/time on which the task was created? 2) If point 1) above is a legitimate situation which meant the task immediately expired after it was created, why hasn't the bpm progressed? Are you able to obtain the task ID and show me the result of that query to confirm what we think is happening? In the mean time I'll see if there's a way to rescue the stuck BPMs. Thanks, Dan
  15. Hi Mike, thanks for your post. I hope the HR team found the "Hornbill for HR" demo insightful. Currently, an "Add attachment" field isn't available for us to add on a custom form which means it's not possible to achieve the single pane layout you desire. The form which I believe was of interest was the standard "Add Attachment" form available in Progressive Capture. This is shown below and does feature three ways to interact with it when adding an attachment: Click to choose a file using file explorer Drag and drop Paste a screen shot Having one or more of these attachment options available as a custom field type would be a great addition to custom forms and give us even more flexibility should we wish to consolidate forms. Dan
  16. Hi Mark, thanks for your post. There's a short video which discusses some frequently used Service Manager Application settings which can be found here: https://wiki.hornbill.com/index.php/Service_Manager_Settings . This outlines the available notification settings, one being a notification to the team when a new call drops into their teams' queue. If you check out the video from about 2mins 26 seconds hopefully this will give you what you're looking for. Let me know how you get on. Dan
  17. I'd suggest creating your measure using the table h_itsm_request_team_assignment. This table stores a record of all ticket assignments that take place in Service Manager and stores the previous team who had the ticket (in the column h_previous_team_id) and also the team to which it was assigned (in column h_team_id). It also records assignments to individual agents too. For your situation, we're really only interested in the fact that it was assigned to that team, but of course there could be more records in this table indicating assignments between agents in that team. So, we want to count the records where h_team_id = "the/team/id/of/the/team/you're/interested/in" AND h_previous_team_id != h_team_id For the benefit of others who might come across this thread, I'll just to try and illustrate where I'm coming from here, below are two records relating to the assignment of IN00000026. Lets say I want to only understand how many tickets have been given to DANCORP/ITSERV/SUPP over the course of the month so I'm not interested in the reassignments to individual agents within that team (i.e. the record with h_id = 20). This means I want to ignore records where the previous team id is the same as the new team id because if these two columns are the same, I know the assignment action has been within the team, rather than between two teams. The Data Source Configuration in your measure will look something like this: There is of course one scenario where this query would include multiple assignment records for the same ticket and that's if DANCORP/ITSERV/SUPP worked on a ticket, assigned it elsewhere, and then the other team assigned it back. Whether this matters will really depend how your teams work together. If the assignment back to that team constitutes a second round of effort, it might be worth recording in the count. Let me know if that helps Dan
  18. Hi Stephen, thanks for your post. Just to clarify what you're after, would I be correct in saying that you're looking for the number of assignments that a team has had during a month, whether that be an initial assignment of a ticket or an escalation? Essentially, how many tickets have passed through that team within the month, regardless of which team the tickets started with and which team they ended with? Thanks, Dan
  19. Hi Mark, that's not currently a feature of the Request widget, at the moment it's designed to return all requests belonging to the customer. The only thing in this area relates to offering a read-only view of the closed requests. This is governed by an application setting (found in Hornbill Administration > Applications > Service Manager > Settings) called: servicemanager.portal.requests.readOnlyClosedRequests Unfortunately, at the moment the only suggestion I can offer to achieve the outcome you're looking for is to remove the customer from the closed requests. Admittedly, this isn't a great suggestion as its rather laborious and you lose an easy reference to who the customer was for a ticket. There's also a chance that this potentially effects some reports (if you have any which focus on the customer or any attribute of the customer). Whether this is a realistic suggestion depends on what the overriding objective/need is. I hope that helps, Dan
  20. Hi @Mark (ESC), there's a short introduction to Service Manager Application settings available on our wiki here: https://wiki.hornbill.com/index.php?title=Service_Manager_Settings . The video gives a 5 min overview of some of the most common ones we get asked about. There's a minute spent on some relating to the soon to be deprecated service.hornbill.com which of course can be fast-forwarded through, but there rest are good to be aware of. Thanks, Dan
  21. Hi Mark, in order to access self-service, Basic Users require the following roles: * Basic User Role * Self Service User You'll find this information here on our wiki: https://wiki.hornbill.com/index.php?title=Roles under the section "Which roles should I associate?" However, what you've posted there (AADSTS50105) looks like an exception generated by Microsoft Azure so (assuming your basic users have the right roles in Hornbill) this is probably not directly related to Hornbill. If you're getting this message I'd speculate you have Single Sign On configured to some degree and you have Azure acting as your identity provider (IDP) i.e. the thing that authenticates users. Azure, as an IDP, provides a layer of governance in terms of which users are actually permitted to use an application (in this case Hornbill). The error here could be due to the fact that you haven't permitted users within your organisation to access the Hornbill application. This is done by associating user objects to the Hornbill Application which exists in your Azure tenant. This Microsoft document outlines this: https://docs.microsoft.com/en-in/azure/active-directory/manage-apps/add-application-portal-assign-users I'd suggest you speak with your Azure administrator who will be able to check the situation with Single Sign On and also app permissions in Azure. For reference, our documentation relating to Single Sign On can be found here https://wiki.hornbill.com/index.php?title=Single_Sign_On_with_SAML_2.0 I hope that helps. Best Regards, Dan
  22. The fix for the defect identified above was delivered in Service Manager build 2017 released on 9th September 2020: Corrections to the visibility selector when updating Request's sub-status {PM00163555}
  23. Hi Mark, As well as the wiki pages that Steve has provided, we also have a couple of webinars that you may find useful. Introduction to Hornbill: https://www.youtube.com/watch?v=G8xKPMUZYV8&feature=youtu.be - this one's great when it comes to getting orientated with Hornbill as it dips into the various areas. It touches on Business process and progressive capture from about 20 minutes in. Business Processes and Progressive Capture in Hornbill: https://youtu.be/Fsbn_IBFALA - this one focuses specifically on workflow. Customised forms are part of Progressive Capture which is covered from around 30:36 in the video and it also looks at working with customised forms. I hope that helps. Dan
  24. Hi @Jamie A, no worries, glad to hear it! Dan
  25. Hi Jamie, thanks for your post. The following report definition should show you what you need. This can be uploaded into your Hornbill instance by creating a new report and then clicking the option to upload a report definition file: This report will list all the full user accounts which are the accounts consuming a Hornbill subscription (h_sys_accounts.h_class = 1). Basic users don't require a subscription. It will show the full users with a status of active or suspended (i.e. h_account_status = 0 or 1). Archived full users do not consume a subscription (i.e. h_account_status = 2). I hope that helps, Dan utility---hornbill-subscribed-users-report.report.txt
  • Create New...