Jump to content

Hornbill Staff DR

Hornbill Product Specialists
  • Posts

    282
  • Joined

  • Last visited

  • Days Won

    19

Everything posted by Hornbill Staff DR

  1. 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
  2. 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
  3. @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
  4. 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 ÂÂ
  5. 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
  6. 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
  7. 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 ÂÂ
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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} ÂÂ
  13. 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  ÂÂ
  14. Hi @Jamie A,  no worries, glad to hear it! Dan
  15. 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
  16. Hi @Chris Bardell,  "Just to clarify, when this call is getting logged it switches from the Default Rule to our P4 rule? If so, it does show this in the Timeline from switching between the Default Service to P4." As long as the priority isn't being set elsewhere (i.e. in the progressive capture) and based on what I can see in the business process design, yes, I believe this is how it's currently behaving. When the BPM reaches the "Start Response" node, because there isn't a priority set at that time, it will set the "Default Rule" Service Level. Then a few seconds later, once the bpm has updated the priority to a P4, a re-evaluation will take place which should result in the "Priority 4" Service Level (obviously, I haven't seen your rule conditions, but based on everything else I can see, this would be the chain of events). When the re-evaluation takes place, you should see an entry in the timeline which looks like this: As it sounds like there isn't a need to do any triage in this situation, If you always want this request to be a P4, I'd suggest moving the "update priority" node to a position before the "Start Response" and "Start Resolve" nodes. That will mean the Service Level should evaluate to your "Priority 4" Service Level straight off the bat. This will more than likely eliminate the sitaution you're experiencing, however it would be good to understand why this is happening. I'd still be interested to know the response target of your "Default Rule" Service Level to see whether it supports the following: My current speculation is still that this is what we're seeing: where if the existing target has already been met or breached, the met/breached flag will remain unchanged upon a re-evaluation. In short, the re-evaluation updates the new Service Level target time, but doesn't change the state of the fix/breach flag. What I suggest is, as you have a Hornbill Premier Support Plan, you raise an incident with our Application Support Team. They will then be able to determine if it is the situation I describe, or whether there is something else at play here. Include a link to this forum post so that they have the history to begin. Thanks, Dan ÂÂ
  17. Hi Lee,  unfortunately, I'm not sure I have enough information to comment. Does your last post still relate to the Single Sign On configuration in Azure, or are you now encountering an issue with users logging into Hornbill? I'll go with the most common situation when people get to this point. If there are problems logging in to Hornbill, it's usually due to the attribute being passed in the "NameID" element of the SAML Payload. Following an authentication attempt by a user, the identify provider (in this case Azure) will send a payload to Hornbill which tells us whether that authentication attempt has been successful or not i.e. the user is known to the identity provider. If it was Successful, this payload also contains other information including the "NameID". NameID is something defined in the SAML 2.0 standard, and Hornbill retrieves the value found in the "NameID" element and tries to match that against the "Login ID" property found in a Hornbill user account. So if you look at the contents of Login ID in a Hornbill user account, you'll know what Hornbill needs to complete the login for a user. Now we know that, how do we find out what the identify provider is giving us as the NameID, and how is this configured? This bit is done at the identity provider's interface, in the bit where you've configured SSO for the "App" (in the case of Azure) or the "Trust" (in the case of ADFS). As you can gather, each identity provider has a slightly different way of doing it (and the terminology might differ too). For Azure, once you've navigated to the SSO configuration related to Hornbill, you need to find the section titled "User Attributes and Claims" (https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-saml-claims-customization). Here you define what Azure sends to Hornbill in that SAML payload I talked about above. The Azure "Unique Identifier" is carried by the SAML payload as the "NameID" which in turn is matched against the Hornbill "Login ID" to complete the Single Sign On process. By default, Azure sets the userPrincipleName as the unique identifier. If you're coming from the world of Active Directory and ADFS, you'll likely have chosen the Login ID in Hornbill to be the samAccountName. As we know, the UPN and SAM Account Name are quite different in their content. Therefore if Azure is sending the UPN as the Unique Identifier, Hornbill wont find a match among the user Login ID's therefore the login can't complete. Fortunately, Azure still supports the samAccountName and it can be found in the list of attributes available for selection against the "unique identifier". It's called onpremisessamaccount (or something similar). Obviously, that's quite a specific scenario, but a common one given the path many are taking in the adoption of Azure. The crux of it is to make sure the identity provider is sending a value in the SAML "NameID" that matches what your Hornbill user accounts have as their Login ID. I hope that helps, it's certainly allowed me to get that knowledge out into the community! Thanks, Dan
  18. Thanks Chris, That's great, thanks. I'm going to guess your Service Level rules will be based on Priority (i.e. you'll have P1 to P4 which result in the corresponding service level Priority 1 to Priority 4, and some "Long Term" priority which evaluates to the "Long Term" service level). Let me begin with some background: When the "Start Response" node is reached, the system will evaluate your service level rules to determine what service level should be applied, and therefore what the target response time will be. If my assumption about your rule set-up is correct, the service level will evaluate to the "Default Rule" Service Level when the ticket doesn't have a priority. Further on in your process, I can see a node that is labelled "set priority to P4", which I assume will do just that. The priority is a field that, when changed (either manually by an agent or via the bpm), will trigger an automatic re-evaluation of the service level i.e. the system will review each of the service level rules in turn and set the appropriate Service Level, which will probably be your "Priority 4" Service Level. I'll digress momentarily from the issue we're exploring and just highlight that blindly setting a priority (in this case a P4) isn't necessarily best practice, unless the process is specifically designed for a particular type(s) of request that always attract that particular priority. Firstly it can lull you into a false sense of security, in that its been prioritised and the assumption is that "it's fine, I've got 1 day to respond", whereas in reality nobody has triaged the ticket and you could have a P1 or P2 masquerading as a P4.  In an ideal world, when it comes to incidents, or if this is a process intended to be for any request, all tickets should be reviewed within the time allowed by your strictest service level (most likely that response target related to a P1 e.g. 1 hour). This ensures that should you identify a P1, you will be well positioned to respond within your stated commitment. This is where your "Default Rule" service level comes in, which is considered Hornbill best practice. In the past, I've called this the "Triage Service Level" as it's set on the occasions where a priority is yet to be determined. The benefit here is two-fold, firstly it applies a service level to the ticket giving the agent the required targets to work towards. Secondly, this particular service level is not bound by any priority, and having a request sat in the request without a priority makes it clear that the severity/urgency of the ticket hasn't been determined and thus it must be reviewed. Should it be found to be a P4, this can be set by the agent, the service level is re-evaluated, and the targets increased. Anyway, coming back to the issue at hand: In one of your screen shots above, it clearly shows that the target is marked as missed, but the target is actually 09/10/2020, which is in the future. So what gives? The only situation I can think of is that the service level was re-evaluated and set to a "Priority 4" at some point after the response target of your "Default rule" Service Level had been exceeded. Currently, if the existing target has already been met or breached, this flag will remain unchanged upon a re-evaluation. In short, the re-evaluation updates the new Service Level target time, but doesn't change the state of the fix/breach flag. What's the response target of your "Default Rule" Service Level? Dan
  19. HI @Chris Bardell,  thanks for the additional info. So far, nothing is jumping out at me. I think the root of this behaviour may lie in when your response timer is started, and whether or not a different service level is set initially, then subsequently re-evaluated. Please could you tell/show me the following: A screen shot showing the location of your start response node, and also the mark response node in the same image A screen shot of the the Service levels you've created in your Service Request SLA The aim here is to get a bit more of a broader perspective on what is happening in the process. If you can provide the above screen shots, I don't think your process definition will be necessary. Thanks, Dan
  20. Hi John,  the location of the upload and create document buttons have since moved. They've been consolidated into a new button which is now located to the bottom right of the screen. The primary button, which is red, will create a new Hornbill Document. Hovering momentarily will expose additional buttons for Uploading a document and Creating a link to an external document (this latter option is simply a shortcut to the external document).  I hope that helps Dan
  21. Morning Chris,  thanks for your post. The crux of the issue seems to be around the the response being met/breached. More specifically in the case of where it's breached, I gather that's the situation you feel isn't correct. To advise further we'd need to understand: What the response target is for your Priority 4 Service Level in your Service Request SLA A screen shot of your Working Time Calendar showing your hours of operation Can you provide this information? Thanks, Dan
  22. Hi Lee,  thanks for your post. Are you referring to the action of adding users to an Azure app (in this case Hornbill)? If so, I believe the ability to add groups (rather than individual users) requires Azure Active Directory Premium P1 or P2 edition. https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/assign-user-or-group-access-portal Dan ÂÂ
  23. Hi John,  with regards to the question around the menu options available within a service, these are not configurable right now. However, some will only be shown if there is content available in that area. Your options for serving up knowledge content to users would be to leverage either of the following: Documents: These can be stored in Hornbill Document Manager (https://wiki.hornbill.com/index.php?title=Document_Manager) and made available by associating Documents to a Service (https://wiki.hornbill.com/index.php?title=Service_Details#Documents). I see you already have the Documents menu option available. Service Manager FAQ's: FAQ's are a feature of Hornbill Service Manager and are ideal for presenting smaller amounts of information or where a document is not required (https://wiki.hornbill.com/index.php?title=Service_FAQs). When you have one or more FAQ's available, a new menu option will appear labelled FAQ's. I hope that helps, Dan
  24. Hi John,  further to my last post, development have kindly prioritised the work to introduce the solid background colour to the logo. All being well, this will likely be available towards the end of next week. Best Regards, Dan
  25. Hi John,  I believe the positioning the logo in front of the background image was a conscious design decision to make better use of the screen real-estate. However, there are also plans to expose a setting which would add a solid background to the logo which would overcome the situation where there is little contrast between logo and background image. For one reason or another this doesn't appear to be available to us now, but it's something that will be added. In the mean-time, a suggestion might be to create a new logo on a solid white background and use that. With regards to the button to logout, this can be found in the navigation bar which is exposed when you hover over the tab shown at the top of the screen:  ....then click on the user icon located to the right... ...and then clicking "Log Out" Dan ÂÂ
×
×
  • Create New...