Gerry

@Berto2002 Lol you are probably right, absolutely no one likes to be accountable for their time, especially down to the granular minutes level. However, there is a reality that goes along with being able to charge for time spent, and that is, you have to justify that time, this is one of the reasons why at Hornbill we try our best to charge for, and be accountable to outcomes and not hours... if that makes sense. We are always looking for good feedback and suggestions, everything that gets suggested and asked for is considered at some level or another. What is important to understand is we are serving a lot of customers, and we see a lot of variations in use, operational practices and requirements, and what we have to do is balance every individual need with what is good for the general population. If we over-populate the features in every area of the product we end up in a place where most customers will complain about complexity, and they would be right to do so. So in your example above, while I totally understand you appear to have a need to record time against, say, linking a call, as a product team its our job to question that. Is that a feature that would benefit customers, does it make sense, or is there a way to better use the product that would make even more sense, and when it turns out to be the latter, in the absence of any other insights we should be advising you of that alternative way, which I hope above I did and it makes sense. Timesheet is currently a free "application" that all customers that subscribe to Hornbill can make use of, its free because we know that its not perfect, and it certainly does not really compete with some of the stand-aline timesheet tools that are out there today, but its big advantage is it is perfectly integrated to the reset of our system, in that regard our customers today see Timesheet as a "feature add-on" rather than an application in its own right. One day though, we will probably introduce Timesheet as a stand-alone and chargeable application so we are always looking for ways to improve it, so we very much appreciate it when people do take the time to ask questions, make suggestions and so on, but we are selective about what we will do as Hornbill generally is more like an "off the peg" solution that you can customise rather than a "bespoke per customer" solution that we build for individual customers. "what is the best way to frame our positive requirements to you to be best received and reviewed?" I am often one of the people that considers these requests as I know our strategic product goals very well, so I would say, if the request makes sense, if there is something to learn about how companies (by which I mean our customer population, rather than any one individual customer) may get more value from using Hornbill then we are always happy to build that into our thinking and our backlog for considered inclusion. There is no doubt our customers know more about their operational needs than us, and we are very greatful for all that take the time to help is fly the Hornbill plane so to speak. I would say, the kind of "our directors are not happy because we do not have X" - when you have an alternative way of achieving what your directors want, feels a little like a veiled threat, thats not a particularly good way of getting stuff onto our queue - I would suggest Sorry for my candid response here, but I think folks that know me tend to know I can be forthright for the sake of brevity. Gerry

@Berto2002 From what I understand it, the actions chosen are broadly the actions that require you to enter some written information, which is broadly in line with how one would use a timesheet. Now you have rightly said that some actions, for example finding a call you want to link too can take more than a few seconds. What I would suggest here is this is an operational issue, and not something you should seek to solve with a product feature. If it were me, it would make sense that when I record time, I would want to add some form of narrative along with that time recording entry. You could tell a POSITIVE story to your directors by simply ensuring operating procedures mandating that you always perform a text/timeline update where time recording is required. This way, you might, for example, link two or more calls, you might categorise the call and you might link a service, all as part of the same action, you could perform these actions and then finally do an Update action where you write your narrative and record your time. Especially if you are using this data for billing, you are going to want to pull detailed narrative in the cases where your customers ask you to justify your charges for any given time spent. I am pushing back slightly here because I am not convinced that having options to record time on actions that are *often* just a couple of seconds to do is needed for most customers, but I do appreciate that in some operational cases those sorts of simple actions could take more than just a few seconds - this though can easily be overcome taking the approach I have described above. If you were asking for actions that have a text input that contributes to the customer-facing request updated to also include time recording that would make sense, but I am not sure any of the highlighted actions fall into this category. I am not sure what your goal is to frame this question/request as something you need in order to not tell a negative story to your directors, I think you could easily tell a positive story to your directors if you adopt a way of working that meets what is being mandated by your directors, you can of course choose to tell a negative story if you wish, thats really your choice and if you feel thats necessary then I doubt there is anything we can ever do to the product that will change that. Gerry

@HHH obviously you can add such a line to any of the email templates you use, but thats not going to address any of the issues I have highlighted above. Basically, there is way to reliably do what you are asking, to attempt to add such a function would basically lead to a feature that does not work sometimes that would be unsupportable. Gerry

@HHH I was not aware we even had a such a line in the template, and to be honest I am not sure why we ever would have added this. The issue here is, even if its our line that we have added to our template, there is absolutely no guarantee that a receiving or even a relaying MTA would not alter the underlying markup, in a way that we would be able to reliably re-detect. From a pure technical point of view there is no easy way to detect this, at the very least it would be unreliable to try and do so... "Delete everything below the line" and thats the other part of the problem, *even if* we detect the line, we cannot blindly just remove all text below the line, because its HTML markup and the structure of the message body would break, causing other problems either for Hornbill or other email systems. This is the problem with trying to do this... Gerry

@HHH There is really no reliable way to make this work. The diversity of formats found in emails, apart from plain text which is generally easier to deal with, most email now days has an HTML body, and even worse there is no standard format adopted, so email can come in almost in any format. So trying to intelligently segment the email message to what is meaningful and what is not, is basically an impossible task - at least to get to to work consistently. My understanding of what "Reply Above The Line" typically does, is provides a placeholder somewhere in the middle of the email message where the originator of the message would like you to insert your reply, most email systems that I have seen do not recognise this nor do they truncate the content either, thats left up to the email replier to make a judgement, that is at least what I have seen before. So there are two problems, the first is identifying "the line", which could for example appear in HTML like <p><span>the li</span> ne that needs to be recognised</p>, or any one of a billion combinations to achieve the same. The second problem is then deciding how to truncate that message without breaking the HTML structure. The general reply above the line practices that have been adopted by some people and systems appears to be generally considered a very bad idea and for the above reasons I tend to agree. The problem comes down to the way people use email, they basically *expect* the recipient to do all the work, and that has more to do with email culture than it has to do with technical limitations. I am happy to hear alternative views or ideas here, but as I am often wearing the "how to implement" hat I see the problem through that lens. Gerry

That would appear to be a defect, it should not do that. Will make sure we sort that Gerry

@Alberto M Thanks for your comments and thoughts. I wanted to reply because I think its worth keeping things in context. We at Hornbill more than anyone feel the pain when things go wrong, today and yesterday have been particularly difficult days to manage because a couple of impactful things have gone wrong, and mostly when things go wrong these are due to change, the big thing for most IT people to face. Its a balance, change and risk breaking things, or leave a long and become outdated. With regards to testing, you said "make more testing in new releases and patches before making them live" and what I would really like to point out is we do, in fact we put more combined effort into testing and test automation than any other single development activity, testing is our number one priority. However, Hornbill has many millions of lines of code, there is a lot of moving parts and sadly despite our best efforts and often immense levels of test coverage and daily effort, things still do get missed, go wrong or sometimes we experience unexpected external factors. In almost every occasion we have a problem, we count our recovery times in minutes. Sometimes it takes a little more time to understand the nature of the problem we are seeing, and it definitely takes a little time to put in place a good an reliably recovery strategy, we always have to balance the quality of the resolution with the speed of resolution and we need to do that effectively and objectively in an environment that suddenly becomes pressured and hostile as customers rack up the calls for help and resolution. I would ask you and our customers generally to judge us on our overall performance and the overall quality of our service over a reasonable period of time, rather than on the bad day, so to speak, I would hope most customers wad judge us favourably but I will happily admit we are not perfect, this do go wrong from time to time. In terms of todays problem for example, we took the decision to roll back to a previous binary version, that is not something we have done very often at all. Today was different, there were actually four completely independent issues we identified, two of which we had never seen before and did not have test cases in place for, one we had never seen before what we have never even anticipated and another was of our own making, that we should have caught in testing but did not. Every time we see such errors, the very first discussions we have internally is "what tests do we need to add to ensure this case is never encountered in production" and every time we add these cases as a priority over fixing the code, then we fix the code knowing there is a test to verify the fix, and to guarantee no re-introduction. The point is, we do take testing very seriously. I understand that none of this helps any customer who is depending on Hornbill to do their day job, or where it is mission critical, and I can only apologies to each and every customer where there is impact, both personally and on behalf of Team Hornbill, but I would hope our customers would generally understand that when we make changes, and when that leads to such problems, firstly we don't do that on purpose, and b) we will do whatever it takes to resolve that issue. The alternaive to our current approach is to move away from CD and instead, say do bi-annual or annual releases, forcing our customers to do upgrades like most of our competitors do in this spec. I personally hate that idea because that is essentially making our customers responsible for the upgrades. I believe strongly that most customers, on-balance, would rather see positive change and evolution of the tool they rely on daily, and to avoid such big upgrades. I hope that makes some sense to you Gerry

Fair point on status.hornbill.com, this is not as automated as we would like it to be. In the heat of trying to solve an issue it tends not to make the top of the priority list to get status.hornbill.com updated. We will try to do better next time. Gerry

@John C We will post some more information regarding the service outage, we had a global, we will publish an RCA in the coming hours. In terms of your question, I am not sure I understand what you are asking. "I am about to kick off a migration to another tenant" another tenant of what? "Note I changed both the user id and email in my Hornbill profile but could still not log into service manager, this will obvious affect all end users too." if you are using SAML (as you seem to be) changing your login ID in the Hornbill profile may or may not be relevant, this comes back to the way AD is configured, when AD generates an SAML assertion, it will provide a NameID, this is what we match to in relation to the account, its easy to change all the login ID's in the Hornbill instance, but you also need to understand how our AD is configured if you want SSO to keep working. "Is there a way to import a csv file into Hornbill" yes there are many ways to import data, depends on the type of user (basic, user or contact) and what you want to do, its possible to bulk upload. I am not really in a position to provide specific support on what you need to do, I am not really an expert either. If you have a success plan in place with out support team they can definitely help with this sort of thing. Thanks, Gerry

@John C We have a production system issue, so this is most likely not related, give us 5 mins Gerry

@John C I think our SAML implementation is pretty well documented already to be honest, but the key to configuring this is to understand YOUR idp and the basics of how SAML works., both of these are really out of our control. Even internally at Hornbill we sometimes have to bring in outside experts to help us with some aspects of our own network like AD and so on, its generally not possible (or desirable) that our technical folks at Hornbill try to be a Microsoft (assuming you are using AD) support house as we are not really Microsoft AD experts, do not have people trained or geared up to support Microsoft products. Our system implements SSO using an industry-standard open-standard known as SAML 2.0, this is industry standard and vendor agnostic, we 100% support SAML 2.0 ( https://en.wikipedia.org/wiki/SAML_2.0 ) and this is how we implement full and transparent SSO across multiple platforms and enterprise systems seamlessly. In our documentation on the Wiki we have provided some examples of how one might configure AD to work with SAML 2.0 and Hornbill SSO, but thats really provided on a best endeavour bases, if there is an oppertunity to improve that documentation we would be happy to take on board any suggestions. In answer to your question "now I wonder why there are 6 as oppose to just 3!?" You will see that you can remove the ones you don't need. Our platform does not randomly make up keys so if they are in there as a result of an import that can only mean those certs were in the metadata that you imported from. You will see on the list that there is a "Used Count" this is telling you how many times each certificate has been used to authenticate a user, the counter is there to help you determine what certs are being used, you also have an expiry date so you also know when those used certs are going to assign. If you have more than one cert in your metadata, this may mean that your particular AD setup has a cluster of either multiple domains and/or redundancy, and it may well mean that your IDP is publishing the fact that SAML assertions could be signed with any one of those 6 certificates, in this case, when validating a user authentication request we will select the correct certificate. Again, this is VERY SPECIFIC to your network/AD configuration and not something anyone at Hornbill would really have any meaningful input on, without that is becoming a proxy support function for your own AD infrastructure. Certificates will sit on our system for 90 days *after* they expire, at which point they will be automatically purged from our system. Its also worth noting, that if you configure the SSO correctly, and, your AD is configured in such a way that our service can reach your SAML metadata endpoint, you can configure this so certificate renewal is entirely automated, you only need to turn that option. This is a feature we added 18 months ago because so many customers seem to be "left to it" by their own internal network teams to manage and deal with this themselves. I would finally point out that the forum is a community resource and not an official support channel. We do our best to frequent the forums and answer as much as we can, but we very specifically state that the forum is not an SLA'ed support channel. Moreover, for requests like this that would generally veer into supporting your own AD environment, or educating you on SAML and how it works, you are likely to get less takers because these things can become very time consuming and difficult to help with. For anything important that is going to interrupt your use of our service, I would strongly recommend you use our official support channel: https://hornbill.com/support/ It seems from the screen above your new certs are not yet being used, so before you remove any of the ones that are not being used I would wait to make sure your AD system starts to send authentication requests using those new certs (you will see the use counter increasing), once that starts happening you will be safe to remove the old certs that are no longer being used (again you will see that by seeing that the old certs counters are no longer incrementing). Thanks, Gerry

@Smurfy It was an internal POC as a tool to help you anyalyze and understand the use of roles and rights, we disabled it because it was as much confusing as it was helpful. We will re-introduce something better in the coming weeks. Gerry

@nasimg the old admin UI is still present on admin.hornbill.com but we have removed the link because its only 7 days way from getting switched off and we are still seeing traffic to the old admin tool, the link removal is our "gentle reminder" that the old Admin UI will stop working very soon, and we do not want a dead link in the menu. You will notice in that drop menu the section where the Admin link used to be is called :Useful Links" indicating this is a section of links to other "external" resources, of which the aol Admin was one. As the new admin UI is now part of the same app, there is no justification for leaving that administation link, especially when you can get at the admin/config area from the little cog icon at the bottom left of your view, or indeed, if you are a power user, by pressing Ctrl-Shift-S from anywhere and type in what you are looking for to administer. Sorry for any disruption, but we have found if we do not hurry these things along, they can stick around forever, which stalls progress, and leaves us needing to maintain two completely separate codebases. Thanks, Gerry

@Jake Thaker I think what you are describing there is a "30-day" view which is distinctly separate from a Monthly (calendar) view. I am not disputing the validity for the requirement, but wanted to clarify what I think you are asking for. Just simply setting a start-date will not cut it here, the month view is rendered as a Calendar view of the month selected, and is by definition a "Calendar Month" view. Implementing a 30-day view would be a different visual presentation that would look more like a timeline or of sorts, perhaps something along the lines of the N Days view rendering in Outlook for example, I think thats what you are asking for. It would be interesting to see how many others might be interested in such a view variation. Gerry

@Dan Munns "I assume that the templates are applied to users as part of the import process and need OUs to identify the users to have the template applied?" to be honest I am not sure how the LDAP import functions with regards to templates, that is something I would need to defer to someone who knows how the importer works. You suggested that "having the ability to create a role group" would solve your problem. If we could create a role group it would be given a name, and potentially you may have more than one of these role groups, so you would ultimately still need to deduce which "rile group" to apply to any given user when importing or auto-provisioning would you not? and this would be the same for the template, in other words it should be possible to use the template (with the role changes) to achieve exactly what you want? Gerry

@Dan Munns @Berto2002 Thats a very good point. I have reviewed to see why this is, and to be honest I see no good reason why we have omitted to create groups as part of a template, both manually or when provisioning via SSO, so I have committed this the 90-day roadmap and will get that implemented. It will be with you soon. Gerry

@HGrigsby Your welcome, its a start and we have lots more to come. I am sure you can appreciate we are doing a lot of stuff at the moment, but anyhing I can get into our release stream incrementally we are doing, this was one such thing, so thank you for the request and for your patience. Gerry

@Adrian Simpkins The URL is generally static, but can change under certain conditions. If your instance moves home, this URL will change. In very rare cases we will move an instance because of resource re-balancing, that may move from one DC to another, or to a different POD/Cluster within the same DC, in these cases that URL would change. The URL would also change under DR conditions where we might be restoring your instance into a different cluster. These events are rare, but when they do occur the change could be temporary or permanent. The url will *always* contain the TLD of *.hornbill.com so I would suggest you add that domain to your trusted sites, that will ensure there is never such a problem. Gerry

@Dan Munns Can you not use User Templates, what you are asking for sounds like this is the solution to me? Gerry

@Kelvin Not a problem, I can understand why you asked, but I hope we have long since proved that we stand by our priced for life policy for existing customers, and we generally do not take things away, we mostly introduce new things for free and do our best to encourage our existing customers to take advantage of these things. I am glad your users see a lot of value in board manager, that is where we have gotten to also, where we think its at least close enough to something like Trello that we can justify a charge for it in future offerings, but in doing so we do not want to diminish our service management offering, hence to two variations. Can I ask, were you previously using another boards-type tool before using Hornbill? Gerry

@Kevin For existing customers you are free to use either approach. What is driving our assesment is the fact that the market (being the ITSM market) is telling us they want a simpler offering, and the whole notion of "A Platform" with "multiple applications" is too complicated an offer to the market. What @Ehsanis mentioning above is really relating to our ongoing internal packaging conversations, so any changes in this regard will only impact future offerings, our priced for life commitment remains firm for all existing customers. Today Board Manager is a free application, so there is no commercial reason not to use it. Board Manager is far more functional than the board built into SM, so our intention was to encourage as many of our customers to take advantage of this while they can. Our commercial intention is to offer board manager as a priced option as an alternative to something like Trello, but in Service Manager terms, we still feel we need to have a basic boards capability, so we are looking essentially at keeping both options. You are free to use either capability and both will be supported, there will just be a less premium and a more premium variation that customers can choose, both systems are usable from SM and the BPM so there will be no direct impact to existing customers. Hopefully that clarifies our position a little better? Gerry

@Stephen.whittle Each application will get something that looks like this, you will be able to see whats in the accepted backlog, the 90-day commit, whats in progress and what has been completed in the last 90 days. Lots of customers have been asking for this, so its nearly here... not all apps will have this straight away, but we our expanding each project to include this information. Gerry

@Stephen.whittle Upcoming feature in the new admin solution center is our published roadmaps so you will be able to see everything thats in the pipeline. Gerry

@AlexTumber The other alternative would be to add a "boards style" view of contracts based on some dynamic criteria like we do in the tasks and a couple of other places. I can see that being very useful as a visual aid for contract management. Gerry

@will.good Looking at this, its not something we will be able to do without a lot of re-structuring of how the SSO implementation works. Its not just a case of checking another entity, in order to get the SAML assertion in order to check the NameID / LoginID that means we would have to try all of the configured SSO profiles one at a time, and that would be entirely implemented and orchestrated by the front end code redirecting back and forth between the IDPs and our service. This is not at all recommend or supported by the standard, it would be bad practice to "just try them all" and it would create a terrible UI experience for the users trying to log in too, and given the amount of work required to even try to make this work, and the very high risk of introducing defects, this is not something we can implement I am afraid. Thanks Gerry