Jump to content

DanielRi

Hornbill Product Specialists
  • Content Count

    256
  • Joined

  • Last visited

  • Days Won

    18

DanielRi last won the day on March 23 2018

DanielRi had the most liked content!

Community Reputation

70 Excellent

About DanielRi

  • Rank
    Product Specialist

Profile Information

  • Gender
    Male

Recent Profile Visitors

2,290 profile views
  1. 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
  2. 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 t
  3. 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
  4. 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 request
  5. 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
  6. 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
  7. 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}
  8. 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
  9. Hi @Jamie A, no worries, glad to hear it! Dan
  10. 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_accou
  11. 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 bp
  12. 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 tha
  13. 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
  14. 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
  15. 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
×
×
  • Create New...