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

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

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

@Sandip Bhogal 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

@Gareth Noon 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

@Adrian Simpkins 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

@Gareth Cantrell 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

@Steve Giller 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

@samwoo When I first read this I thought, that makes sense, could not be that hard. Then I thought about it a little more and I am not sure we could do this, at least not in a way that would allow WTCs to work for their intended purpose. The primary goal of a WTC is to allow the measurement of SLA's over working times (as opposed to time elapsed). When doing such calculations, we use WTC's for example, to take a point in time, and determine a future date/time based on the number of working seconds from the starting time point. Our use of WTC's rely on these predictions to be correct. So for example, if an SLA is working towards a time where it has calculated an escalation, taking into account (correctly) a bank holiday on Monday next week, then you suddenly add that day back in as an inclusion, then even though the escallation has already happened, all of a sudden according to the referenced WTC that escalation point has no longer been reached. Now of course, we happened to have used WTC's for other things, like calendars and appointments, which I think is where you are referring to, so probably this is something that would need to be accommodated outside of the WTC. Or we would have to have different types of WTC's, some for SLA related time calulcations and some for managing available working hours in calendars. Not sure really, I was just responding with an initial brain dump, I am not completely familiar with all the places WTC's are employed so we would need to give this requirement some consideration so we did not inadvertently cause other unexpected problems. Gerry

@AlexOnTheHill Changing the team structure is easy, but the hard part is all the other parts of the system and applications that reference those teams. For example (and this is just one of many), when you set up a workflow assignment node to assign to a team, if you delete that team, your workflow will still reference that team, and, in that case things will break. Now scale that up to the numbers of workflows and historic data records and you will start to get a sense of the scale of the problem. The general advice would be - don't delete teams... unless you really understand the consequences. Some useful documents that may help: - https://docs.hornbill.com/esp-fundamentals/core-capabilities/organization-and-teams https://docs.hornbill.com/esp-fundamentals/best-practice/org-structure Gerry

@will.good To exapnd on Victor's response above. It is certainly possible to change the h_user ID value for one or more users, BUT, its very complicated to do, and could break many things. The h_user_id field for legacy (therefore backwards compatibility) reasons is the primary unique identifier for a user account. This means, there are a large number of other areas that are going to be referencing that ID, so if you change the ID you will break those referrential links, these could be anything from simple ~FK references in other tables, references to the user(s) from within workflow and ICs and many other places that reference the primary identifier. So while its technically possible to do it, you will likely break lots of things doing it, and so we generally recommend that you dont make such a change. Many customers use opaque values for this field, often things like the users AD SID or other such thing for this exact reason. Hope that makes sense. Gerry