Gerry

@Nithan @gemma.jones 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 assets you are browsing on the left, selecting an asset in the list would show the asset 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 asset 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 Assets (and requests and other lists for that matter) by following the modern them of split view navigation for browsing large data sets. Gerry

@Jim 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

@Caroline 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

@Caroline 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

@Caroline I think this section should help https://docs.hornbill.com/esp-config/security/sso/single-sign-on#sso-auto-certificate-renewal-and-sso-certificate-expiry-reminders Gerry

@SteveJM 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

@Ashley 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

@James Ainsworth 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

@HHH 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

@Martyn Houghton 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

@Alisha 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.

@JJack 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

@Martyn Houghton Thanks for the clarification, I will discuss internally. Gerry

@Martyn Houghton I do not have the answer here, but I wanted to clarify, are you talking about "agent-side" or "customer-side" of LiveChat? Gerry