Gerry
-
Posts
2,437 -
Joined
-
Last visited
-
Days Won
172
Content Type
Profiles
Forums
Enhancement Requests
Posts posted by Gerry
-
-
Basically exactly what @Steve Giller says, page the data out. If there is too much data for 6 months, try three, or one for each month of the year, consolidate the results in your working data sets.
-
As I understand it, there is an item on the roadmap for re-working the request list, it does not appear on the published roadmap for some reason, but yes, this has been discussed previouly, including taking into consideration your previous suggestion. I am not directly involved with the Service Manager roadmap so I don't have the details, I asked last week that we update the published roadmap with the things we have planned so everyone can see whats coming down the line.
Gerry
-
1
-
-
As you mention, some tools show you the details of a record and then provide a previous/next buttons to zip through the records. The problem is, thats mostly quite a bad user experience, its a hangover from the days old data base programs like MS Access (see screen attached as an example).
As has been pointed out, the problem with this is what previous and next mean becomes problematic because the source list of things you are browsing are no longer in view, the context of the list is lost and that makes for a pretty poor experience, and not something we would like to replicate.
Now thinking about what you said here "the ability to click through a list of asset records rather than having to exit each record to open up the next one would be very beneficial and save time.", this I agree 100% with, and, IMHO prev/next buttons would not be the way to do it, a much better way that would deliver a far better user experience would be some kind of split view, so you can have the list of request you are browsing on the left, selecting an asset in the list would show the request properties on the right.Its a funny thing that when customers ask for something specific, we often seem to talk about the requirement in the exact form being asked. By making the point.... "the ability to click through a list of request records rather than having to exit each record to open up the next one would be very beneficial and save time" that gives us options to meet the need without being so prescriptive about how we should go about meeting that need. I am not directly involved in the product decisions being made in the SM product, but I thought I would post here for your benefit and ours internally too.
So FWIW I would suggest we could vastly improve on the UI for Requests (and assets and other large lists if items for that matter) by following the modern theme of split view navigation for browsing large data sets.
Gerry
-
As @Steve Giller mentions above, there are many internal API's, some of which relate to email, however, those API's are used for hornbill's UI's for performing their function.
Email API's are not exposed as customer-facing API's because Hornbill is not intended to be used as an Email proxy so we could not think of any reasons within the scope of "integrating with Hornbill" that would need such API's. That was our thinking, it does not mean we are right of course, there could be scenarios where that would make sense. If you beleive there is a valid use case, please see the document relating to our roadmap and feature requests/additions that covers the sorts if things we take into account when considering an enhancement request.
https://docs.hornbill.com/esp-fundamentals/about/about-roadmap#requesting-enhancements-or-feature-requests-for-inclusion-in-the-hornbill-roadmap
Gerry -
Thanks for the feedback, to be honest I also noticed this today. It seems we have ported the text from the wiki verbatim and not edited/reviewed the documentation, so I can only apologize for this. We should have done a much better job here, this is not the quality levels we want our documentation to be at. I have flagged internally to get reviewed and improved/updated.
So yes your understanding is now correct. Keep in mind that, depending on your IdP configuration, that metadata may/may not be publicly available, the best way to check is to get the URL, put it into the field on the SSO profile and you can press the reload button to the side of the URL field and press it, that will make our servers query the URL to look for the metadata. If you get any error when doing that manually, then auto updates of your certs will not work.
I will make sure the Configuring SSO documentation is updated and improved and the screenshots/illustrations are provided.
In terms of the frequency, when SSO auto cert updates are enabled, Hornbill will check your metadata once every 24 hours.Thanks,
Gerry
-
No thats not right. Your IDP (aka Azure AD or whatever you use) will auto-renew certificates, thats a function of your IDP. When you configure an SSO profile in your Hornbill instance, you can configure it to periodically check your iDP for updated certificates, and, if Hornbill finds an updated certificate, Hornbill will automatically import those updated certificates into your SSO profile.
This is all described in here: https://docs.hornbill.com/esp-config/security/sso/single-sign-on#sso-auto-certificate-renewal
Gerry -
-
In regulated environments, you are often required to keep an accurate record of data processing systems, identifying the type/nature of the data being processed, so that when you are audting for things like GDPR you can provide evidence of the data processing systems and the records associated with them.
Gerry-
1
-
-
They are, and you can, the table is called h_sys_lists and its contents is pretty self-explanatory so you should not have any trouble with it.
Gerry
-
Yeah i agree 100% its quite important. The max time is 72 hours, this should be plenty for any scenario I can think of.
Gerry -
In practice, we do not need a long amount of time to access your instance when providing support. Creating a passkey, is, by definition creating less secure access to your instance, this is something we only provide because we have to, we would rather not have the capability in there at all. For almost all use cases we have experienced, they keys are more than adequate from an active time perspective, they are designed to allow you to grant us limited, short-term access only. Our support team should not ask for keys that last any longer than is needed, and we would rather not hold such keys for long periods of time.
I think if we are asking for keys again and again I would probably be inclined to look at why we are doing that, I cannot think of any support scenarios that would make this a common thing?
Gerry -
The problem is, basic user accounts are by design, very restricted accounts, and changing the security model around that is complicated, both technically and in alignment with our subscription model - which its self is deeply embedded throughout the code. Basically, if a basic user account cannot do something, thats because its intentionally made that way. In particular, the writings here...
https://docs.hornbill.com/esp-fundamentals/in-the-cloud/subscription-model#subscription-model-in-principle
So the question is, what are you trying to achieve specifically, and does that use case fall within the spirit witin which our subscription model is defined. Before doing any development work he I would need us to get clarity on what is required specifically, you mentioned "Data Providers" generally, but then yo mentioned a specific use case which is for a Basic User to be able to look up an Organisation. As I mentioned, the current restriction is purposeful because we never envisaged any need for a basic user to be able to browse/see/select from the external organisations database as a basic user would not be doing any part of a workflow that would involve them "participating in the process of providing service".
I am not saying there is not a valid use case, but I am asking the before we consider a change like this I would like to first understand the use case for it.
Thanks
Gerry -
No one likes a UI change, a different look can be initially disconcerting, but I find when software I use changes like this, I tend to give it a week or two to see if my personal preferences adjust, they almost always do.
I don't know about your org, but for example, at Hornbill we all use Office365, and in the same vein, we don't have any control over the font that Microsoft has selected for the Office365 UI, and they do this for good reason, because typography like other style elements are very subjective choices driven by individual preferences often. They have design experts that define these sorts of things so no one else has to think about it.
It would be impossible to continually refine a high quality UI for Hornbill if the font can be changed on a custom-by-customer basis, doing so would lead to an endless stream of "this screen does not look right for me", and we would never be able to please all the people at the same time. Se we see the UI font selection as a UI design choice, not as a customer configurable option, so there is no option to change the font I am afraid.All that being said, we are not trying to make the user experience worse for anyone. The argument of "some users preferred the other font" is probably not going to be enough for us to switch fonts, but if you can provide a more objective reasoning and specifics that we could take back to the design phase and see if we can address those while stiil remaining true to the design reasons we decided to change the font in our design language.
Does that make sense? Can you provide more specific/objective points around the issues with the selected font?
Gerry -
This has been implemented and will be in a platform release in the next week or so.
The Direct Outbound Email View has been reimplemented. The basic premise of this change was in recognition that the management view provided previously was not very useful. While it was "Outlook" like, and allowed you to browse the emails that has been sent, it was less than functional when it comes to administrators needing to track down problems. For example, in a Workflow log, it would report that the authoriser email failed to send, providing you with a message ID. The problem is, when you went to the Direct Outbound view there was no way of entering in a message id, no way of searching for a recipient email address, or email body for things like a Workflow ID etc.... Further more, the direct outbound view did not give you any way of easily seeing if one or messages had failed delivery, and generally no way to search for deliver status and so on. This leads to customers needing to either a) poke around in the underlying database, or b) call us, to raise a support request and have us ( being support ) to poke around in the underlying database. These changes are designed to make sure that customers can more readily help themselves, making the Direct Outbound Message view a *useful* administration tool.
The following changes have been made...- The view is now a tabular view, rather than a "try to look like outlook email" view
- Have added the ability to search/filter by all the useful criteria, including message ID, recipient, sender, and advanced search for subject, and of course filter by delivery status to just see the emails, for example, that have failed delivery.
- The email preview opens up the exact email sent so you can see its content
- The email preview shows you the red/green icon next to each recipient so you can see the delivery status of the message, as well as retry the delivery attempts if you want to.
-
Quote
Is it possible the process did not (or could not) wait for, or coordinate itself with, the re-delivery attempts of the email.
I would not have thought so, when the message is sent, its queued and the normal mail delivery semantics, including retries for non-hard errors are applied. If the delivery attempt gets a hard rejection, for example, address not known at this server, then thats considered a hard error and the message is rejected, in this case our server will mark the devery attempt as failed and will no longer retry delivery. This looks like what happened in your case, it looks like a hard delivery failure, but I cannot be sure without seeing the message delivery log for the failed recipient.
Mail delivery logs are actually stored in the database, and in this case would be stored against the message recipient record, so I imagine the log is there, its just not easy for you to see without delving into the raw database - which is not a very customer-friendly thing to have to do - hence the suggestion if you log a call, one of our techs can get that out of the database for you. Once the changes are added to the product you will be able to go and see this yourself without our assistance.
Gerry
-
-
1
-
-
I do not have the answer here, but I wanted to clarify, are you talking about "agent-side" or "customer-side" of LiveChat?
Gerry
-
We have added this item to the platform roadmap, and its made it directly into the work in progress queue, so I would expect this to be generally available in the next couple of weeks. Once this is in, we will aim to extend the BPM logging such that the message ID its self will be clickable, and that will take you directly to the offering/failed message, all to make issues like this simpler for you to diagnose and rectify. Look out for this in an update soon.
Gerry
-
2
-
-
Thanks for your post. Your question is fair, and the answer is, at the moment, without peeking under the hood in the database, locating the mentioned delivery log is difficult. Basiclaly, if you can find the message in the Direct Outbount Mail view in the platform admin, the recipient for that message will have a red envelope next to it, and clicking that would open the detail of the message delivery log. The Direct Outbound Mail view though does not make it possible, given a message Id to easily locate the message which is a bit rubbish I am afraid.
So....
- If you log a support request with our team, they can get someone to peer into the database and locate the message/delivery log in question
- In the mean time I will ask someone in the platform dev team to look at/rethink that (not very useful) Direct Outbound Message view and improve it to make diagnosing mail send failures like this much easier.
Gerry-
1
-
-
Its relatively trivial to add a control so you can prompt for just a time, but I am curious to know what you would want to do with that data? If its just for collecting information only, then thats simple enough, but if you are planning to use that in calculations or feed into other components for some kind of automation, that might be a different thing, as we may need to consider things like local time etc... if you could give is a brief outline so we understand better what you want to achieve, we can probably better advise you what may be possible.
Gerry-
1
-
-
I think the above thread is basically saying we are not going to be able to add a sort option, so no, no movement on this ask I am afraid
Gerry
-
Thank you for your inquiry. Let me provide an overview of the strategic adjustments we're making at Hornbill regarding our platform's collaboration and user feature sets.
In 2015, we launched the Hornbill ESP Platform with a primary focus on collaboration capabilities, during a time when Slack was just emerging and Microsoft Teams was yet to be introduced. Historically, our clientele has predominantly utilized Hornbill for its robust service management, workflow, and automation solutions. Over time, this has led to the Hornbill ESP platform being the backbone for our Service Manager application, which is tailored to support these specific use cases.
Our internal teams at Hornbill actively use our collaboration capabilities, but we've observed a shift in our customers' preferences towards mainstream solutions like Microsoft Teams for their collaboration needs. This has highlighted a lesser demand for our proprietary collaboration features, prompting us to reassess their integration within our platform as a you-get-it-weather-you-want-it-or-not non-option. Despite this, the core of our collaboration technology—centered around an innovative "Activity Streams" implementation—remains integral to both the Service Manager application and other Hornbill applications on our platform. It's this core functionality we're preserving, while opting to decouple general collaboration features (such as workspaces, conversations, and integrations with expressive features like Giphy integration) from the platform. These features are being remodeled into a dedicated application, aptly named "Hornbill Collaboration."
The rationale behind this change stems from several insights:
- Our recognition that while collaboration features are valued by some, they are not the primary reason organizations choose Hornbill. By separating these features into a standalone application, we aim to streamline the platform for users focused on service management, workflow, and automation.
- Feedback has consistently shown a preference among our users for adopting corporate standards like Microsoft Teams for collaboration. This decision enables us to align our offerings more closely with our users' preferences and reduces potential friction in adopting Hornbill alongside other established collaboration tools.
- Our internal use of Hornbill Collaboration has revealed varied adoption rates across different teams. By evolving our collaboration features to better meet the needs of development and product-focused teams, we aim to enhance productivity and user satisfaction.
- For both current and prospective customers who find the collaboration features unnecessary or distracting, this move simplifies their experience with Hornbill, presenting a more focused and efficient toolset.
This strategic realignment allows us to offer our collaboration tool as an optional application within our app store, rather than a default component of the platform. This approach reflects a broader trend towards modular, customizable software solutions, enabling customers to tailor their Hornbill experience to their specific needs without compromising on functionality or usability.
Regarding the implications for existing customers, rest assured that this transition will not affect your current use of Hornbill's collaboration features. If you're currently utilizing these capabilities and wish to continue doing so, the process will be as seamless as installing the new "Hornbill Collaboration" application from our App Store, this will replace the platform deployed features, and eventually the platform features will be removed. This ensures continuity and support for your existing workflows. Looking ahead, we're exploring the possibility of transitioning the collaboration application to a paid model. This decision is driven by our commitment to delivering value and ensuring that the features we offer are both impactful and actively utilized by our customers. However, I want to emphasize that this change will not affect our current users of the collaboration features, ensuring a smooth and uninterrupted experience for those that are currently using the collaboration features of the platform.
Our goal with these changes is to enhance the overall value and effectiveness of the Hornbill platform for our users, aligning our offerings more closely with our customers evolving needs and preferences.
Gerry
-
3
-
I have added my comments internally, I have myself been victim to this particular annoyance from time to time, so understand exactly the frustration. I have asked the team to consider your suggestion or an alternative option to ensure there is a way of reversing the accidental escape key press. In this case my comments relate to post/comments in timelines as other fields I am aware of do not have that same behaviour.
Gerry-
2
-
-
Yes I think thats exactly right, its more of a calendar (change specifically) thing, than a WTC thing, one for the Service Manager dev team to consider.
@James Ainsworth fyi...
Gerry-
1
-
MS Teams integration and ability to send messages to users
in Service Manager
Posted
@Emily Patrick
As mentioned above we can already "integrate" with Teams via iBridge, you can use that in an AutoTask and assign that auto task to a custom button, so its possible now to send a message to a teams user/chat.
But, what I think you are asking for is, can Hornbill have an embedded Client/Interface within the Hornbill environment to interact with users/send them messages via teams instead of email, so like this, instead of having an Email button (the little envelope), we have a teams button, with whatever you would need in the GUI to send a message via teams. Is that correct? or am I mis-understanding what you are asking for?
Gerry
