Gerry

Hello @Adam Toms Sorry for no previous response to your questions. So in answer to your actual question, the answer is no, there will be no impact on your current operating practices and queries, its the exact same data, we are just cleaning up the terminology as it seems to confuse a lot of (even our own) people. If there would have been material change in functionally, we would have given you advance notice and provided a transition of some form. This is a simple terminology change to better reflect the purpose of Sites. We have some customers that use Hornbill for things outside of the more traditional IT Service Management use cases, where Sites are a commonly used term. Unfortunately, Hornbill is not *just* an ITSM solution, we have customers that use Hornbill for external customer support, and sometimes from an external Organisation perspective there is also the notion of Sites. There has been a lot of confusion around what "Sites" (as they were previously called) relate to. So to clarify this, we waned to draw a distinction between Sites as in, your company and its various physical locations, and Sites, as in organisations external to your organisation who you support (when doing external support) who also have the notion of Sites. As what we previously called "Sites" *ONLY* Relates to your internal organisation structure in terms of Locations or Offices, we decided it was better to rename these to help pave the way for further clarity between these two quite different use cases (Your orgs Sites vs your customers Sites when using an an external support context). And having debated this internally a bit more we are likely to change this terminology from Office Locations to juts Locations because a number of people felt, in relation to milti-site internal support there are Locations (being physical places where you might find both people and/or equipment) that you support which are not "offices" as such, for example "Sites" in your particular example, or oil-rigs, or venues or other business specific terminology. So we will be changing this once again to just "Locations" Regardless of what we call it by default, if any existing customer does not like the default terminology they are of course free to use the translations and just change it, as many customers have in the past. However, for us "Locations" would appear to be a sensible, generic catch all that works for all highlighted scenarios. Hopefully that makes some sense. Gerry

@Jim For sure, to be honest, as we have seen greater adoption of Hornbill in the enterprise end of the spectrum, the demand for capabilities to allow customers to develop their own functionality on our platform has been rising sharply, and its something we are planning to address in coming releases, I will be talking about this a lot at Insights this year. We are looking at Enterprise and ESM as a new market really, its quite a different set of needs that ITSM, or IT Service Management used in other parts of the business. Don't get me wrong, hornbill Service Manager and the Hornbill Platform are very capable in this regard, but even with the power of the workflow and automation capabilities, there is a limit to how far that can be pushed. The Hornbill Platform and Service Manager product-market fit today is not where it needs to be in terms of that ESM market need, and does need new product capabilities, much of which is centred around that need for the ability to extend the solutions functionality far more deeply via development type capabilities, so we do have plans in the works. In the mean time though, if there are useful Hornbill automations, or iBridge integrations that we have not yet implemented, please do ask, we can generally add these things quite easily. Gerry

@Jim A large number of our customers use the BPM in a non-technical way. We have avoided adding any developer-type coding capabilities within the BPM because that will lead it in the wrong direction, we already have quite a lot of trouble where people tend to treat the BPM a bit like a graphical programming environment. We have two types of automations conceptually, we have Hornbill automations which as the name suggests relates to automating things directly within your (or another) Hornbill instance, for this there is a whole slew of ready-made automations for you to use. The second type of automation is via integrations, for these we also have many pre-built integrations that you can just use without having to writ code either. I think what you are describing is there are things you want to do from within your workflows that are not currently supported in the Hornbill Automations available? If i have that right, for both Hornbill Automations and 2rd Party Integration Automations we have a policy of adding anything that we think makes sense, and would be valuable for other customers. So if there are specific things you need that we do not currently cover, your first port of call should be to post the specifics of your requirements on these forums with a view to getting those reviewed and added to our roadmap for inclusion. As far as being able to call an API from the BPM, in order to do this developer features are required. We are thinking about how we might make more features available for developers, that almost certainly won't be by making the Workflow system have more coing type capabilities, but will probably include a system to allow you to develop functions, integrations using code that can be presented inside the Wrokflow like we do for Hornbill Automations and iBridge integrations. Thats some way off, but it is in our thinking for sure. Hope that helps, Gerry

Relevant... SQL Operator Precedence refers to the order in which different operators are evaluated in an SQL statement. When an SQL query contains multiple operators, the operator precedence determines the sequence in which they are executed to evaluate the expression. Here is a typical operator precedence hierarchy in SQL, starting from the highest precedence to the lowest: Parentheses: Operators enclosed in parentheses are evaluated first. Parentheses can be used to explicitly control the order of evaluation. Unary Operators: Unary operators, such as the negation operator (-) or logical NOT operator (NOT), have higher precedence than binary operators. Multiplication, Division, and Modulo: Operators like multiplication (*), division (/), and modulo (%) have higher precedence than addition and subtraction. Addition and Subtraction: The addition (+) and subtraction (-) operators have the same precedence and are evaluated from left to right. Comparison Operators: Comparison operators, such as equality (=), inequality (<> or !=), greater than (>), less than (<), etc., are evaluated after arithmetic operators. They are used to compare values and return a Boolean result. Logical Operators: Logical operators, such as AND, OR, and NOT, are evaluated after comparison operators. They are used to combine multiple conditions and return a Boolean result. It's important to note that the actual operator precedence may vary slightly depending on the specific database management system (DBMS) being used. Therefore, it's always a good practice to use parentheses to explicitly group expressions and clarify the desired order of evaluation, especially when combining different operators in complex queries.

@chriscorcoran From what you have described, something along these lines... fromAddress LIKE '%@domain.com' AND subject LIKE '%orangesandlemons%' ought to do it. Basically, as @Steve Giller says, this expression syntax is SQL-like in its syntax. The above will match any from address where the domain is @domain.com and where the word 'orangesandlemons' is contained within the subject. The documentation you need is here: https://wiki.hornbill.com/index.php?title=Inbound_Routing_Rules Gerry

@Estie Its also worth mentioning that the banner its self does not collect or track any personal information at all, this is done on purpose for exactly this reason. The banner is simply shown to "users" of Hornbill (not basic users, i.e. your end users), and as I mentioned before the banner is far more effective than email, because we do not have email addresses for your Hornbill users, and therefore would never email them, we only hold up to four contacts for an instance, the authoritative, primary, secondary and data contacts. If you have a success plan, you can add addtional contacts under that support contract, but again, I think thats probably limited to 5. So I can confirm we do confirm with GDPR data regulations around personal data and permissions-based email marketing, we take the rules around this very seriously. Gerry

@QEHNick Hi Nick, Can i just point out that your statement about it being added to the Employee portal is not correct. The banner was added to the UI for Hornbill Users, as a Hornbill User, when you view the Employee Portal you are still seeing the Hornbill user application. If you are a basic user (which would be your end users) there is no banner displayed here. We have added this banner as we have done every year we have done insights because we have a lot of trouble reaching our contacts by email, a lot of bounces, invalid emails and so on, our goal is to communicate the event to our customers which broadly speaking are people that use Hornbill on a day-to-day basis. We have made it dismissible, so if it bugs you (as it does me), you can simply dismiss it, and it will go away. It might pop back periodically in the run up to the event. We are not trying to look tawdry and cheap, we are trying to make sure that all of our customers know that we are spending a bunch of money to put on a user event that will benefit (we hope obviously) anyone who comes along, this direct pointer has worked very well, its targeted, we know its only customers that get sight of it, and we have no battles or customers missed with multiple email attempts that only ever partly works. As for the aesthetic, well context is everything, I would agree that its actually quite loud - visually that is. Possibly not much help, I hope this does help to explain why its there though. Thanks. Gerry

Hi Dan, Currently in-house, we have a good handle on the situation thus far, but have a lot of things to go through. If there is any customers-specific data exposure we are prioritising these for immediate disclosure which we should have done in the next day or two. As previously stated, none of the customer networks, data storage or systems we compromised, only administrative data (files more specifically) that we have on our general network file servers where exposed, we are currently working through that content to determine if there is customer-specific PII or other data that needs to be reported back to individual customers. Gerry

@sjg As per the announcement (and for anyone else's benefit looking at this), I can confirm that there has been no compromise of customer instances or any production instances that run the customer instances. If this ever does change we will be the first to let you know, but as of now, the impact of the issue is only Hornbill's own internal network, which is 100% separate (physically and logically) from the production networks. Gerry

@QEHNick As mentioned above, if you provide our support team with a passcode to access your system to aid with a support issue, this is the button they will use to enter the passcode you provided. By default this button is not visible because its not very useful to users generally - but, you can make it appear when you are on the login screen by pressing the SHIFT key. I expect you did that accidentally which made the button appear. Gerry

@Gareth Cantrell By way of an update, webhooks now include a couple of changes that should help out with what you are doing. 1. You can now add an expression to dynamically control when a webhook triggers, based on the data that triggered the webhook. The UI includes a syntax highlighting editor and some basic intellisense support for when you are creating the expressions. 2. There is a new option, that if enabled, will send all values in the record in the webhook payload, and not just the saved fields, this should get you the primary for a record when its being updated indirectly as a related record from its primary record. 3. There is a new option that, if enabled, will use correctly formed JSON in relation to non-string values. Because of a hang0over of using XML without any schema, values in the payload are all strings, this option will switch that to use JSON native integer, numerics and booleans instead of putting those values in quotes. This has to be an option because of backwards compatibility. This should all be available in the next 2-3 weeks. Gerry

@Gareth Cantrell Following a code review, I have added an item to our 90 day commit backlog for WebHook expressions. In essence, for each webhook there will be an option to specify an expression. If no expression is specified (the default) then the webhook will always trigger. If you specify an expression, the expression will be evaluated before triggering the webhook, and, if the expression evaluates to false, then the webhook will not be fired. Its most likely that the expression will be limited the fields that you see in the webhook event message. The expression is SQL-like syntax, so the same as what you would typically see on the right side of an SQL WHERE clause. I am not sure how useful this will be in real life, but so much of whats required to implement this is already in place, so its a very simple code change and does not need to sacrifice any performance, and creates the opportunity to run more efficiently if you only ever need to trigger certain web hooks dynamically based on certain data values, so is a no-brainer of an addition. Watch out for the change in the platform release notes in future weeks. In relation to the other question about getting extra information when firing a related entity webhook. As I expected, this is much less self-evident, the code paths are complex and so we will have to create an end to end set of tests in order to carry out an evaluation of what could be done to improve things here. However, again, a simple amendment to the existing behaviour is to add an option to include "non-modified" record data in the webhook record payload, so this may well resolve your immediate question as it should include both the record primary key, and the FC values. There is one further option included in this change. This needs to be enabled, but basically this is an improvement to the JSON payload. Historically we have supported XML, but at some point we added the ability to choose XML or JSON as the webhook payload data format, but did not address the fact that while XML serialization relies on XML Scheme to determine datatype representation, JSON has limited datatype representation, in layman's terms, this means, from a JSON payload you can differentiate between text, integer and numeric values. We cannot enable this by default because that would be a breaking change, but there will now be an option so you can use the native JSON serialisation if you want to. Gerry

@Gareth Cantrell In the roadmap and under active development is something we are calling business rules. Different to web hooks, but will have conditions that trigger actions, so some of what you are doing with webhooks you will probably be able to do with business rules, but should be easier to maintain. To be fair though, conditions on web hooks is actually not a bad idea for consideration. I am always conscious of over-complicating Hornbill when we consider features, but WebHooks are really an advanced feature of our enterprise offering so I don't see why we could not add conditions to web hooks. From memory, everything we would need to be able to apply a condition check over the record relating to the web hook is in our hands and we have an ultra fast expression evaluator that could be applied to that exact data. I will add a review of the code to see how viable that is. In relation to the question about the events, in your example, I believe the event for ChangeRequests is actually being fired as a result of a Requests entity update, meaning the API that was called that caused the ChanegRequests to fire a webhook was in fact an API call to update the Requests entity, which has the ability to update a related entity indirectly. So the record being updated is a related record, hence the FK value, as opposed to the requests primary key. It *may* be possible to provide the primary key value of the main entity that was updated under these conditions, I am not exactly sure, again I would need to look and see whats possible without breaking things or sacrificing efficiency. Its not likely the code change that will be the issue, its setting up the replication and test environment, and the subsequent add of automated testing, so time is needed here. I will post an update once we have had a look at whats possible here. Gerry

@Osman It seems that you can set the DKIM selector at the point you create the domain and enable DKIM, but once its set, you cannot edit it. I am not sure that logic is correct, I expect what was intended was, once you verify the DKIM status it should then prevent you from editing the DKIM selector. I will ask someone to have a look and verify this to confirm Gerry

@Steve Preston If you use the "Logged In" status of a user account, you will find this can be very unreliable if a) the users do not properly log out, or b) if the users have multiple logged in sessions, which you can prevent by enabling the disableMultiLogin system setting. You mentioned "Shifts App" within Microsoft Teams? What would that give you that the current availability status options do not? What I am wondering is, how we might consider improving the way availability status works to better facilitate "time windows" which is what I am guessing the Shifts App does? Interested to know your thoughts? Gerry

@Stephen.whittle Watch this space.... Gerry

You never need both certs, typically on AD there are two certs, one is the signing the certificate and one is not, Its the signing cert we need to validate SAML assertions. The use count tells you how many times that certificate has been used to verify an incoming assert, in your case zero, which would imply that since the new certificate has been installed on the Hornbill instance, no SAML assertions have been signed using that certificate. So the obvious question here would be, are your users using Hornbill? are they getting logged in OK? This is an example of a working one Gerry

@Adrian Simpkins as @Jim has rightly eluded to, email templates and embedded images are a bit of an art form, there is an entire industry sector focused on just this because most marketeers need help with getting email formatting right for all the different possible email clients, devices and screen sizes. It does very much come down to experimentation and testing on all expected devices, platforms and screen sizes, or pay a specialist to do the same, or to make use of their knowledge. Basically, its not easy, and can be a real pain in the royal A** to get right. Not much help I know, but what you are battling with is not unusual and honestly not really related to the image library in Hornbill. Now the one think I always do is, make sure the images are a in JPG format and make the images natural size *about* the same size you expect to see it on screen, thats always a generally forgiving approach to start with. Gerry

All, We have added a new system table h_sys_pagevisit_log which will record page visits, this is effectively an extension to the history/bookmarks implementation. In addition, there will be a new system setting system.pageVisitLog.purgeAfterDays which will control how much history is kept, this will default to 90 and is settable anywhere from 7 to 365. This log will tell you who is visiting which pages, but will not log any page/application specific data. There is no user interface to view/display this data, it is envisaged you can use reporting to query what you need. This is a trivial addition so no real planning required, a simple addition, so will be in the release pipeline over the next 2-3 weeks. You will not have to enable anything once released, it will start recording page visits automatically. Gerry

@Berto2002 Thanks for the suggestions, I will make sure to tag this and consider options. Gerry

@Ashley In the case of reports, we purposefully did not include the ability to BCC reports. Here is the reason, suppose a manager has created a report to extract information, let us say for example, any HR request that relates to salary changes. Now consider a rogue admin who would also like to know about this, they could add themselves as a BCC to the report, and, importantly when that report is delivered to the manager (the legitimate recipient), that person would have no idea this report is also being received by someone else too, because the other party(s) are blind copied. This was a very intentional commission from the general functionality of emailing reports. Can I ask, what is your specific use case for needing to blind-copy a report to recipients? Gerry

@Berto2002 For the places in Hornbill that use Email there is not always a direct translation to other channels. For example, we have in the user profile a users email address, we do not have any place to put a teams ID or any internal knowledge of the teams system, and how email message formatting, to/cc/bcc and subject, template formatting and other email specific things in the context of teams, which is not an email system. Not everyone uses Teams, some people use Slack, others even use Hornbill, and there are many other such alternative systems to email that companies have been rolling out for a number of years. To address this properly we would effectively have to abandon on the notion of email notifications/communication in the context of requests and genericise the UI and feature set in relation to notifications/manual updates to work with multiple communications channels such as Slack, Teams, Jira, Hornbill and other collaboration-like tools as well as email. There is a lot to that, its not a simple change. The alternative might be to leave the email behaviour exactly as is, and add a second option for other channels. I will add to the list of things to review and consider for a future change/enhancement, but this will not be a quick thing to address. Gerry

What is the use case here? What are you trying to capture, and why? How would you use the captured information about changes to user accounts? What happens in your organisation that would require this? Thanks Gerry

@Malcolm All that being said, having reviewed the above doc myself, there are specific instructions for configuring Hornbill SSO for Azure on Microsoft's web site here (this link is also in the above SAML 2.0 document) https://learn.microsoft.com/en-gb/azure/active-directory/saas-apps/hornbill-tutorial Gerry

@Malcolm We are not generally experts in any particular directory service, and do not provide support or specific system guidance, and as a result generally do not maintain specific instructions for specific systems. However, we do have guidance on our implementation, and configuration of SSO/SAML 2.0 which is the industry standard for enterprise SSO implementations. Our implementation is easy to configure in Hornbill The wiki page you need with links and information relating to various systems, and the guidance we have can all be found here. https://wiki.hornbill.com/index.php/Single_Sign_On_with_SAML_2.0 Azure Directory Service is highly configurable and each company probably uses it in a slightly different way. You will need to be, or need someone in your organisation who is admin competent/qualified with your Azure AD deployment, who will easily be able to configure Azure AD to work with Hornbill. Gerry