Jump to content


Hornbill Users
  • Content count

  • Joined

  • Last visited

  • Days Won


Lyonel last won the day on April 13

Lyonel had the most liked content!

Community Reputation

120 Excellent

About Lyonel

  • Rank
    Senior Member
  • Birthday January 20

Profile Information

  • Gender
  • Location

Recent Profile Visitors

927 profile views
  1. @Mohamed mixture of everything
  2. Connection and Service Portal visibility

    @James Ainsworth I will speak about my personal case here (which is probably "unique" to my company). We implemented Hornbill following ITIL best practices & recommended processes. As such, for some incidents or service requests (because Changes are not visible via the service portal) more than 1 person could be involved. When such situation happens, there are no "sensitive data". Just an issue to fix ASAP. I totally understand you standpoint and agree with it. But in our case, it would just not happen as we (service desk analysts) control the connections and all our customers are internal people (no external customers) therefore even in the event of a mistake, it would not be a major problem. In our case, the published problem mechanism works well but because we stick to ITIL, problems are only logged once the same incident happened at least twice. And this rarely happens (after 18 months of Hornbill we only have 13 problems logged). A typical scenario is: --- EMAIL RECEIVED / REQUEST LOGGED --- A customer / user logs a ticket because a particular service is not working properly, via email (80% of the time) That customer copies a few of his colleagues who also have the same problem We fix the issue and use the service portal to publish updates and let them know how we are progressing Customer / user confirms the fix by clicking "It's working" --- END OF REQUEST --- During the resolution of the incident, all parties (customer + connections) would like to be kept up to date with the progress considering it is impacting their daily job. If we had to create a problem on top of the already existing incident, this would generate: Great confusion for users - which ticket should I look at? Why do I have 2 tickets for the same problem? Great confusion for analysts - which request should I update / work on? Not fully respecting ITIL (unless 2 or more customers log requests for the exact same issue => quite rare in our case | they rely on emails CC-ing people) Extra admin work for IT staff Reporting / Data analysis would be trickier as we would need to remove "duplicates" manually. In my opinion, the real disconnect at the moment is as follow: We are trying very hard to NOT work so much with emails but get people to log onto the service portal and follow the progress from there (and provide updates & feedback, read FAQs & bulletins, etc.) Connections cannot see the request via the portal Customer has no way of sharing the request except via screenshots or "print" functionality of the browser (NOT the built in functionality available in Service Desk - wiki) Customer does not receive a nicely formatted email when we post an update on the timeline Connections are not notified they are added to a request We therefore only have 1 option to update the users (incl. connections) about our progress: e-mail Again, this is our personal situation and I very well understand it is specific to us. But at least you now have, I hope, a clearer picture of our challenges If not, we can always have a chat over the phone. In terms of technical solutions, why not had a few options for the customer on the request's screen such as: When connections are added, the customer has a choice to make all posts with visibility "customer" to "customer + connections" [that could be translated to "me only" & "public"]. The customer would then have the choice to make the whole timeline public or remain "private" (via a modal with simple / clear description of the process and its risks) Customer, when posting an update would then have a choice of visibility (like we do in Service Desk): "me only" or "public" Connections could post updates but they would be "public" by default Basically, why not move the decision from the Service Desk staff to the customer? But still allow connections to be added and view the request? And why not offer your customers (like myself) the choice via a setting to "allow connections to see requests their associated with" (giving the service desk full control) and another setting "allow customer to select visibility of posts" adding an extra layer, more granular, where the customer is in control? If you use facebook messenger (and probably other social media tools) when you add a new person to an existing conversation you get a warning saying that this new person will see all previous updates... That's my inspiration for this idea. Sorry about the long post, I just hope it gives you more context, understanding and ideas on how to progress this topic.
  3. Connection and Service Portal visibility

    @James Ainsworth In our case, we would not really worry about the visibility... Another option could be to add a simple level of visibility when connections are added to the request. For instance: Customer & Connections (would only appear when connections are added to the request - not possible to set as a default) Customer Team Owner If you do that, then all previously shared information is still hidden from connections. When adding the first connection, a modal could offer to turn the visibility to "Customer & Connections" on and apply retrospectively. Choice is then given to the Service Desk Analyst. Also, any post set with "Customer" visibility could be upgraded to "Customer & Connections" (but not downgraded once read - as it is the case today). Anyway... I have quite a few ideas on how to work around the challenges related to information shared previously. +1 for this change! It is starting to be critical for us... As we are trying to eliminate the emails, we need connections to view requests too.
  4. @TrevorKillick Did we lose the "history" tab during the latest release? I know there was some kind of issue before...
  5. Just to confirm that the fix around "Division" / "Company" with the ID is working fine now
  6. Thanks @TrevorKillick! Much appreciated, I will keep an eye out for the next release and resume my testing then. By the way, I really like v3 of the tool. Much better than the previous version. I have to admit that as a developer myself, I very much appreciate the continuous improvement, effort and time you guys put in improving things (even if they work just fine). Good job !
  7. Reporting on User Type (i.e. Basic or Full)

    Use the field "h_class" 3 = Basic 1 = Full
  8. @TrevorKillick I think there is a small bug with the organisation section in the Hornbill Admin UI: Both options "Division" and "Company" have a value of 4 (instead of 4 and 5 respectively). When selecting the option "Company" and then go to the debug tab: I would expect to see "Type": 5 If you get a chance to include wiht the next admin console release? That would be fab! I cannot progress my testing with this issue unfortunately But to finish on a good news, thanks to this new version of the tool I managed to reduce the number of imports we need to do from 34 to 21 !!
  9. Thanks @TrevorKillick for the very very quick response! I will modify the page size to something more reasonable too (like 100) and continue my testing.
  10. @TrevorKillick just ran it again with 1000 page size and it went through ok.... And the -logprefix just after config works well
  11. @TrevorKillick back to 1000. I'll try the -logprefix too (as recommended)
  12. Good shout @TrevorKillick! I changed it to 50 and it worked like a charm. Maybe the data is truncated on the server side if the page size is too big?
  13. @TrevorKillick sent by private message