Jump to content


Root Admin
  • Content Count

  • Joined

  • Last visited

  • Days Won


Gerry last won the day on April 15

Gerry had the most liked content!

Community Reputation

239 Excellent


About Gerry

  • Rank
    Senior Member
  • Birthday 03/19/1966

Profile Information

  • Gender
  • Location

Contact Methods

  • Website URL
  • ICQ

Recent Profile Visitors

2,568 profile views
  1. @Dan Munns I notice today that this has been added by our dev team. it's currently in beta for review, once we have seen internally it should make it out to production in the next week or so. Thanks for the suggestion Gerry Gerry
  2. @Dan Munns One of our devs will take a look at this over the next couple of weeks, we are not sure what's involved but I can see the benefit of having this capability and if you are to use DM as an alternative I can understand why you would not want to lose this capability. Watch this space... Gerry
  3. @Trevor Tinsley Thanks for your comments, the position was not supposed to be dismissive of any need, if it came across that way I apologize. We do understand that IT is seen as being responsible for HSM and its important for you to be aware of all and any changes, this is why we set up the update forum above so you can be notified of changes in advance of you applying those changes with regards to the Service Manager and other applications. I think @Victor was simply trying to highlight that we are in the future (due to overwhelming customer demand) will be making these updates automatic, which means they will get applied for you in the maintenance schedule window that you define. I fully acknowledge that there can be issues that arise but I can assure you we take our testing/validation very seriously, and we always look for ways to improve our approach, and we very definitely do not use an Agile approach so as we can abuse or compromise our approach to quality. We have good data over the last 15 years or so, and hands down our customers get an overall better experience by a very long way, our the number of support issues and the nature of those support issues tells us this. It would be a terrible situation, and we would have failed in our mission, if our customers need to be notified in advance of changes to our software and have to do their own testing/roll-out plan every time we do a release/update, most customers don't want to do that, or be involved at all, which as I said is what I am told by many customers is one of the key drivers for buying into a SaaS solution with a Continuous Delivery approach. We prove our service to all customers with a zero contract tie in which we believe allows our customers to vote with their checkbook, if our approach, our service does not live up to the needs of their organization they can leave without any contractual obligation, everyone at Hornbill knows this so we are compelled to always do the right thing, software quality is a big part of that, if we do make a mistake it is certainly not intentional and we will do everything necessary to put it right as soon as we can. Thanks, Gerry
  4. @Kelvin Thank you for the vote of confidence. As Keith mentioned above, you can get notice of any change by simply following the above forum topic, that will tell you about every release because posting to it, is entirely automated. Gerry
  5. @Trevor Tinsley I wanted to jump in here and expand on what @Victor was saying, I hope you don't mind. It is difficult for us to add forward publishing of change in a way that would be consistent and would not stifle progress. In delivering our SaaS platform we made a very conscious decision about going down the route of continuous delivery. To make that sort of commitment we had to really rethink pretty much everything we do. You mentioned. This is a fair statement and I can understand your concern, but if you actually look at the numbers as a relative measurement, the number of issues is a microscopic number in comparison to the number of changes that we do make and push out to improve the overall service to our customers, and I believe that in counter to your comment above, I would hope that our customers derive a great deal of benefit from a service that is overall predictable, available, safe, secure, always up to date and essentially evergreen. Customers (save for the current app update button) do not have to be concerned with updates, upgrades, migration plans, data migrations or planning or time for any of the above, the idea behind our approach is we do all of that for you, all of the time so you are unencumbered and are free to doing your day job rather than maintaining a system you use to do your hob. Now, I will be the first to admit that we are a software company, run by human beings, and as such there will be something we miss and there will be the odd thing that will go wrong, and by accepting that we are able to commit to continuously drive improvements in functionality, performance, security improvements, and we strongly believe that if you look at the service over its lifetime, overall that's a far better approach for our customers. We cannot ever guarantee to never break anything, no software company can, but we do everything we can to minimize this and we can guarantee that if something does go wrong, we have an office full of the worlds most experienced Hornbill platform and applications people, who will prioritize fixes and resolutions to problems above all else, most problems we can (and do) fix in literally minutes. This approach appears to work exceptionally well for our customers in the vast majority of cases, but it's not an approach that is on the face of it, naturally aligned with more traditional change managed approach. The alternative way to do this would be to stage our releases, to say quarterly or bi-annually where we document every single change and like one of our competitors provide you with a 40+ page document that gives you information on how to "prepare for an upgrade", offloading the responsibility of testing, migration, backups and all that good stuff to you - the customer, that would fit more neatly into a traditional change control process, but honestly, we hate that model because of our past experiences, and think in today's world of IT, complex business applications are better delivered as a service, and the vendor should be entirely responsible for updates/upgrades and data migrations. We actively promote this evergreen approach when we sell Hornbill, and this is often one of the factors for customers choosing our solution. Many of our Hornbill customers who have been users of an n-prem solution that does have more traditional upgrade approach, like our own Supportworks tool, I would like to believe would support the idea, that on balance, the Continuous Delivery approach we take with Hornbill is hands-down a better approach than the infrequent "upgrade" model and "upgrade projects" of the past. Back to the original question, it's very difficult for us to document an FSC without substantially changing our process, many things are fixed and deployed (and documented in release notes) in a timeframe that's faster than writing and publishing the change in advance of deployment, as soon as we do that we are inviting bigger customers to start wanting to "gate" our releases to tie in with their own change processes, which will be especially true when the application update button has been removed altogether (a very popular request from our customers). To try to give some justification to this approach, we are Office 365 users, we have no idea what version we are on, and what updates are applied and when, Microsoft do all of that so we don't have to worry about it, and I have no interest in knowing what they change either, all I care about is when I need to access my email it just works, or if I need to open a spreadsheet I can. I would like our customers to think of Hornbill in the same way, that's been our vision for our platform since inception. I hope that goes some way to explaining our philosophy and approach. Gerry
  6. @Dan Munns In a browser, yes, although we are looking at integration with O365 so that might offer some support here. For the inbuilt documentation, I will ask the question internally, if it were doable this is where it would be most easy to achieve. Will keep you updated. Gerry
  7. Hi @Dan Munns Just a clarification, what sort of document are you talking about? Inbuilt document types, or when you upload, say word or PDF documents? Gerry
  8. @Lauren @Ann-MarieJones As luck would have it, we were working in this area of the code over the last few days. While we were in there we have added a new setting to profile codes which, when set, will do what you want and sort the list of profile names without case-sensitivity. This change has been made to one of the core application services so it will take some time 1-2 weeks to work through the pipeline most likely, one of our dev teams will also need to make a small tweak to the Admin tool to present this option. So give it 2-3 weeks and this option should be there for you. Gerry
  9. @Cizzling I will be sure to keep you informed also, I am hoping to pull together a small CRM focused working group to explore what areas we should be looking at with regards to external customer support. I will try to arrange a timeslot for an initial discussion on the topic an INSIGHTS 19 if you are able to come along. Thank you for your interest Gerry
  10. Hello @Martyn Houghton Yes, I would love to have more structured talks around the customer portal. One of the things we have recognized in our own approach is internal portal is a very different thing to an external portal, while internal needs to be geared towards employee experience, external needs to be geared to Customer Experience, the needs of these two sets of requirements are actually very different and that's why we struggled with a single codebase. For the external customer portal we see this being much more aligned with Customer Manager, and more neatly fits into the CRM category of software functions, this is where we ultimately see our focus, and this is something we are in the process of bringing into our product thinking. There are a few customers, yourself included who would really benefit from this focus and I am committed to driving this forwards. We can certainly organize a session to talk about it, but I would love you to be more involved in this during 2019 and beyond as we expand our thinking and feature set in this direction. Gerry
  11. @Izu Of the two logs, one looks like an incremental import, the other looks like a full import. I believe the tool does both types of import and that depends on the way you run it. I can only assume that both of the above logs were generated from different run method - although that is a just an assumption on my part Gerry
  12. @Izu Its a difficult question to answer without being highly specific. Part of setting up both systems to use email and autoresponder type behavior will be to ensure there is no loops, this is an implementation-specific thing. It is certainly possible to configure Service Manager to not send automated emails on an update, in fact, it does not by default so what you want to achieve should be possible. Personally, I would advise you would be much better off using the iBridge and BPM to log the requests on Jira from Hornbill and to use whatever call-out capability Jira has to invoke our API's to do the same. You will have for more control over the integration and the performance quality this way. Gerry
  13. @Giuseppe Iannacone In regards to the question "and generally speaking why we can have all the field as variables", there are potentially hundreds of variables that *could* be included, it would be very inefficient to load all information into the browser "just in case" you make use of one value, this is why we have a pre-defined subset. Just let us know what you need and we can update this. If this list ultimately gets too big we would need to change the way it works. Gerry
  14. @Joanne Can you post a screenshot of what you mean? It may be your iDP doing what you describe and not Hornbill... Gerry
  15. @Izu I would suggest running such a process at quiet times, there will be some locking and stuff that would slow things down on a busy instance. As for data backups, we do have nightly snapshots, for EU instances they are generally complete by 3AM UTC, so I would suggest an early-morning clean-up would be a good time. The DRYRUN is non-destructive but will allow you to see what will be run against the database, this is not a heavy process and nothing gets locked during a dryrun. Gerry
  • Create New...