Jump to content

Gerry

Root Admin
  • Posts

    2,432
  • Joined

  • Last visited

  • Days Won

    171

Everything posted by Gerry

  1. @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
  2. @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
  3. @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
  4. @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
  5. @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
  6. @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
  7. 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.
  8. @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
  9. @Martyn Houghton Thanks for the clarification, I will discuss internally. Gerry
  10. @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
  11. @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
  12. @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
  13. @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
  14. @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
  15. @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
  16. @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
  17. @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
  18. @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
  19. @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
  20. @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
  21. Hi Martyn, Thanks for the reminder. I had to go back and look before responding. So this is the position so far. We did, a very long time ago make it possible for each application to "extend" the UI in the Auto Responder rule properties to add addtional information. You will see this in action when, for example, you select an action that requires you to select a specific template, in this case, the generic Reference field is refactored to become a drop-down list of templates for you to select from, that drop-down is the application operation specific custom property. In practice, its possible for each application team to show whatever addtional information they like here, which can include a theoretically endless number of fields for addtional information that is passed to the underlying operation, the one limitation here is, the Reference field stored in the database only has a capacity of 64 characters. So based on my last comment above about being two sets of things that need to happen, the first thing needed has already been done. This means that I need to pass over to the Service Manager team to do the second, I expect this might already have been on the backlog, I will need to check, and I will ask someone from the SM dev team to follow up here. All that being said, having had a quick review of the function as is today with a developer, I do want to make a couple of different improvements, which are simple, and now in the works... I am going to expand the capacity of the field that holds the addtional custom information from 64 to 2048 characters, that should be enough to allow for simple JSON structures, CSV's or any other text based multi-value property construct, giving the application team more flexibility as to what they can bring through into settings By default, if an application auto responder operation does not provide custom properties, we show the Reference field by default. In most cases there is no use for this, so we are going to hide that by default so its less confusing, each Auto Responder operation that needs the reference field can resurface it, which will make things easier for anyone configuring these. I am going to arrange for the UI of the Email Routing Rule properties to be slightly re-organised such that the Reference field is removed (as above) and, when there are custom config properties these will be shown in a separate form section, and I will encourage the app team(s) to include in their custom properties area an in-app help popup, like we have already provided for the expression. These changes are trivial, so will get them done over the next couple of weeks, and I will ask the SM team to look at tihs requirement with a view to making use of the above. Hope thats helpful Gerry
  22. @samwoo Appreciate that can be frustrating, I would strongly reccommend that if you are doing long Workflow editing sessions, that you enable this option..... Gerry
  23. @Martyn Houghton Thanks for the clarification. So by the sounds of it a Requests::lookupRequestIdByExternalId() API would get you what you need? It would look for the request where "h_external_ref_number" matches the external reference, and would return the Request ID? Gerry
  24. @Jim @yelyah.nodrog I just wanted to make a comment here. Any database table with the h_sys_* prefix is subject to change at any time. That means you cannot rely on any report you run against those tables to work moving forwards. I appreciate as of today the Hornbill platform through system reporting capabilities allows you to peer into pretty much any part of the database, so you are of course free to do this, its your instance and your data. However, should these tables change as things evolve, and should the platform change in the future to better secure the system for multi-tenant use, you may will find this sort of report will no longer work. With that in mind then, the better question for use to ask is, what are you trying to get/filter by, perhaps if we understand the requirement, we would stand a chance of providing you that facility instead, which would be more convenient for you, and far more supportable by us? Gerry
  25. @Martyn Houghton Can I ask, what API's are you currently using to achieve that? The requirement is perfectly reasonable, however, for us to implement that in a way that is supportable that would require some speciific behaviour. For example, many of our customers now have +millions of request records, so, if your external reference number was just stored into a custom field, where there is no index, then it would be a very poor performing API call as it would have to do a full table scan to find a record. So if this is a requirement we should provide you with the ability to do this via an API, but, in this case, we would probably want to be adding a dedicated field (if one does not already exist) and ensure that its correctly indexed in order to support such an API. This is really the point. The general query API's will let you do pretty much anything, but given our database schema, and general query APIs (like the search API) will and need to change as we improve things, we cannot be continuously locked into API's of the day, as we have been when exposing these. I would be interested to know which API's you are currently using to achieve this. It certainly sounds like something we should be able to correctly accommodate for. Gerry
×
×
  • Create New...