Gerry

@Berto2002 There are multiple issues with trying to implement something like this. Hornbill is not designed to do bulk email distributions in this way, there is not direct correlation between organisation groups (collections of people) and email distribution lists. Technically of course, as you rightly say, the basic function is quite simple, but in detail there are a lot of issues here. Things like GDPR, email permissions and opt-ins/outs, dealing with bounce-backs, out of office notifications, invalid/missing email addresses, duplicate email address and so on are all things that need to be handled correctly. Now I appreciate you are about to say to me that GDPR is not a problem for you because your users are internal, and thats true for a lot of customers, but if we implement such a capability we also have to consider the many customers that use Hornbill, that do not only deal with internal employees but external contacts, then not only do we need to manage opt-ins/outs, but we need to also deal with managing email origin server reputation and all that goes along with that. There is a lot involved even though it sounds simple, in practice its not. I fully understand what you are trying to achieve, and I have empathy with the almost-there bridge image you used, but this is not something simple to do, and its not a common requirement/request, in fact in 9 years this has not come up once in relation to Hornbill. I am not saying we would not implement something like this, as you say most of the bits needed are already there, but its not something we could do quickly or simply. In the mean time, it would be better if you can use 0365 distribution lists, we have some on our own O365 account and they do work. Gerry

There are two distinct situation here as best I understand, let me clarify with you if I may...* The first case is when the receiving party is the wrong person, so long as the receiving party is available to do so, you can simply add a third outcome to the external task to handle this scenario, so for example, the third outcome could be called "Cancel Approval Request" or something else that differentiates from the normal "Reject" outcome . The receiving party can choose this outcome which will resume the BPM allowing your process flow to take a specific path where you can loop back and send a new approval again. * The second case, this is when the external approval has been sent, but for some reason the receiving party does not action the approval, and the service provider/owner of the process needs to progress the process onwards without waiting for a timeout. For this we can extend the admin tool to include the ability to allow the BPM manager in the running processes area, when pressing the resume button while the process is in suspended state and sitting on an external approval node, could present a UI allowing the BPM manager to complete the approval with one of the outcomes configured for that external approval node. This will most likely need some changes in the BPM to handle this, one of our devs is looking at that over the next couple of days, and assuming there are no unexpected technical difficulties we will aim to add this capability in over the coming weeks. If you can confirm that I have understood what you are asking for that would be great. Thanks Gerry

@Paul Alexander You said "up to a point", where do you run into limitations? Gerry

@Paul Alexander Not at all, in my experience you are good at making things work well. I guess what I am curious about is can we make our approvals functionality more flexible to make it easier for you, but also to keep true to the overall design intent. Instinctively, giving the responsibility of something important like an "approval" to a collective where no one is responsible *feels* like a bad idea. Just a question, why not use a task, with appropriate outcomes to achieve what you want, unlike an approval, a task can in fact be assigned to a group or a role? Gerry

@Paul Alexander The authorisation scheme was conceived on the basis that authorisations are individual as opposed to collective responsibilities. From a business process point of view it sounds like a really bad idea to have a group of people responsible for an authorisation. From a practical point of view, one has to manage the conflicts, like what happens if one approves and another rejects, is it a good idea that depending on who "gets there first" a business process could get either an approval or a rejection under the exact same conditions. The problem with weighting per role is that make things not only really complicated to implement, but also really complicated for people to understand. I will take a look at that, as I am not really sure just how much of a change that would be, but given the auth system was built with a view of individual rather than group responsibility, I have a feeling thats going to be very complicated to implement. Gerry

@Paul Alexander The very nature of parallel processing means that one thread cannot break the other threads of processing, so no, it would not be possible to break out of a parallel processing scope until all parallel threads are completed. If this relates to athorisations, why not just the authorisation node that deals with multiple approvals and weighting etc...? this is what its built for Gerry

@Dave Longley A bit late in the day here, but could we jump on a quick zoom call at some point, I just want to find out a little more about your use case if possible. Gerry

@samwoo The problem is there is no perfect answer here to layouts, we either put the buttons on a separate row, or not, and in this case we opted not to to save vertical space. Knowing that the buttons can wrap / exceed the size of the screens, to some degree it is incumbent on you to be sensible with the number of buttons and size of the text on each button to ensure that in most use cases you will not see this problem. What we should do beyond that is limit the number of buttons and post that limit provide a "more" dropdown. The reason we do not do that is we would then start to add the complexity of having to order/prioritise, adapt for mobile and so on. We will look at other options, but our very best option at the moment that is universally applicable is to suggest applying common sense to the number and sizes of buttons you create Gerry

@Ehsan @sprasad @Daniel Dekel I wanted to pickup on one of these points, specifically "Notifications - Descending/ascending order option within the notifications pop-up" and I will refer back to numerous prior discussions and explanations of this point, which I think describes very well why we will not be implementing this. @sprasad You mentioned specifically in the feedback document a couple of points I wanted to respond to directly. I want to say that this has nothing to do with being "important enough", I have responded a number of times to this same request and explained that this is not something we would be changing, we are not going to adapt a generalised notification system into a call request work list. We take every request for change/enhancement seriously, but we also have a responsibility to all customers and their needs. As I have previously stated on this topic, if you want a chronologically sortable priority list of things you need to do, the notifications popup is not the place to do this, this is what the request list is for. It would be better to perhaps think about why you tend to gravitate towards the notification popup list instead of the request list for your workflows, perhaps from that we can find improvements to the request list. You also stated.. I can understand your perspective, but I have to tell you, thats not what the majority of people who were using Hornbill would tell you. The previous UI was dated and of its time, and had many usability issues, these needed to be addressed. Beyond that point, we also have a strategic roadmap which requires us to "keep up with fashion", we have plans to make many changes/improvements all of which require such navigation changes. The previous experience worked fine, in the same way as "at the time" the Windows 3.1 style worked fine, as did the DOS experience before it, but technology, fashion and ultimately demands from users move on, which is why we had (sometimes thrust upon us) Windows 7, 8, XP, Vista, 10 and soon 11, things have to move on, even if not everyone loves every step along the way (we all remember Vista right), I very much doubt anyone who is using Windows 10 today would be happy going back to Windows 3.1. As a vendor we have two choices when it comes to revolution over evolution, we can either a) leave existing customers where they are and release new major versions with breaking changes etc, and impose a "migration" exercise on each customer as we go, or b) we adopt a Continuous Delivery model and we bring our customers through the evolution/revolution cycles with us. Back in the days of Supportworks we did the former, as was common with On-Prem software solutions of the day, but with Hornbill we adopted the latter, and its been very successful for us, adoption rates are 10x higher with Hornbill Service Manager than they ever were with Supportworks and this is largely due to the fact that customer do not have to upgrade/own the technology and are happy to be on the journey. Of course not everyone will love every change, but I would hope that the overall solution still delivers. A continuous delivery model only works if a) we focus on things that are generically useful to all customers, and b) our customers allow us to deploy on a CD basis. I appreciate your judgement that our development efforts could be put to "much better use" and I think if you were the only user we had to satisfy, that would be 100% correct, but we have a diverse range of use cases, in a broad range of companies all have specific needs, and our focus has to be on that bigger picture. Gerry

@Rashid.Ahmed Thanks for the question. This is exactly what Hornbill is built to do, we have many customers that do exactly what you are describing, and there is no additional modules required to achieve this. The only consideration for additions here would be to budget for: - * Any help you need from our customer success team in terms of onboarding your finance team, getting them trained, getting their processes initially built and generally getting them comfortable so they can become self-sufficient. We can do as little or as much of this as you would need us too, or if you are comfortable with the solution you can do it all yourself of course. * You will need a number of additional user subscriptions for those users that will need access to Hornbill in the same way as your current team(s) have access. There are no issues with this sort of setup, we can segregate requests, queues and data in pretty much any way you would need, the security and visibility model implemented on the Hornbill platform is both highly flexible and very robust. Best thing to do would be to engage with one of our customer success folks and discuss what you want to do, I am sure we can get you up and running quickly. Gerry

@Gary.Reynolds No problem, thanks for the feedback, glad the issues are sorted. We have lots of incremental improvements to other ares coming now we have the base changes deployed. Gerry

@Tina.Lapere We are also going to look at a possible hotfix for this particular issue if at all possible, if so, this will be pushed today most likely. Its only a possibility at this point though, so please dont hold me to it - just in case there is something more complicated than we think it might be. Gerry

@Tina.Lapere I am not sure to be honest, I just checked here and for me its working as expected on various zoom levels, What browser are you using? what zoom level are you using? With this information I can ask the question of the devs Gerry

@Tina.Lapere "Is there any way of changing the spacing on the Views as the one I had has now chopped off the last digit on our call numbers for Service Requests" Which view is this? Portal? Analyst Request List? other? Gerry

@Tina.Lapere I will need to ask our devs about this, I really don't know how the height of these things are determined, I will have someone provide some more information here. Gerry

@AndyHill "Is there a way you could provide the ability to edit the size of the tiles so we could return to 3 tiles fitting per box?" I will need to let our devs look at that. I expect the answer would be "not easily" as we are making this code fluid and reactive so you get a good end-user experience on mobile devices as well as in a browser. Having fixed sizes of anything is a bad idea. In terms of the image example you have given in relation to wanting giant buttons, thats actually a very helpful image that expresses perfectly what a number of customers has asked for, i will feed that back into the dev team and we will see what we can come up with. Ultimately, using images is bad if you want your portal design to work on all device types, and it seems to me having this type of giant style button should be an option we could easily provide I feel. Anyway, I am glad all of the other issues are sorted for you, thank you for your feedback and patience. Gerry

@AndyHill Thanks for the update, I am not sure why setting a single size did not make it work. Perhaps you will be kind enough to post one of your images here (and the sizes you had set) and someone in the dev team can try to re-produce the issue? I would however encourage you not to use images here, because we have and are optimising the portal for mobile use, if you have images things will look really ugly on different mobile devices. Its not clear to me why you have used images when you can just use the SVG icons that are available to you, they are the exact same icons that you have used in your image creation. With regards to the other four issues, mentioned above, can you confirm these are now resolved for you on Preview? Thanks Gerry

Hi Gary, Please see my comments below in relation to the 5 points raised in the word document you sent me... 1. In relation to the line under the logo. I have reviewed this with the devs here, and it seems that the line we added was dealing with the fact that the showcase image we were using had an unintentional pure-white blend around the centre of the image, the designer addressed that by adding a line to cater for the image without giving any consideration to an image a customer might use where there was an intentional white space with no break. I have instructed the devs to remove this line for now and this will be pushed to preview in the next 15 minutes. Please confirm you see that? 2. In relation to information missing from the bottom banner, this was indeed a defect, has now been fixed and deployed to preview earlier today, it should be there right now - please confirm? 3. Icons squashed. We have been unable to re-create this, but from what it looks like, this is a simple mis-configuration. We are assuming these blue boxes are actually images as opposed to the vector icons/text you can use natively, this would be better to use. However, if you want to use an image you have the "option" to set both the width and height of these images. If you specify the width, then the height will be adjusted proportional to the width you set, and visa versa, if you specify the heigh and not the width, then the width will be proportionately adjusted based on the width. If, as it appears to be in your case, you specify both the width and height of the image, then the image will be stretched to fit with the original aspect ratio ignored - this is what we believe is what is happening on your configuration. If you can go and remove either the width or height in the link widget configuration, your images will un-stretch. We cannot change this behaviour as many customers would be impacted, so the fasted route to resolution here is for you guys to just go into the portal config page and correctly set the image size settings 4. Icons not centred. This was identified as a defect, in fact, specifically, this is a defect where the top/bottom padding was not being applied in the case where the link items appeared as a single vertical column. This appears to be a bit of a blunder on our part, we should have seen that in testing, but I understand that has now been corrected and is now on preview. Can you please confirm? 5. As best we can tell from the word document, this is a problem that existed, and was already fixed over a week ago. Can you please confirm this is no longer an issue on preview? "All I am asking for is some time for this to be resolved and for my team to resolve the aesthetics." I understand and I hope the above gets us there, these issues should now all be resolved apart from the stretchy image issue. If the stretchy image issue is still a defect then we need to know this sooner rather than later. I cannot hold up the release pipeline for a single instance, which is why I have prioritised all of the above to be promoted to preview now. "Our reputation certainty will not be enhanced by 2500 customers landing on a SSP which looks corrupted." agreed, but I think we have an answer to that now above? Gerry

@Michael Sharp I agree 100% with you on this point, and thats why I say its something very specific to the needs of "service managers", but in Hornbill, the notification system is a *generic* notification system, its not just for service managers, we have people using Hornbill for other things that do not include service management at all. Hornbill is a platform, which amongst other things provides a unified, browser, desktop and mobile notification system. Service Manager (our service manager application/solution) is an application that runs on the Hornbill Platform, so to make the notifications work like a prioritised workload list of people working requests is not in keeping with the design intent and is not appropriate to do. However, there is no reason not to look at adding a different view somewhere inside Service Manager that could address the needs of "service managers to ensure notifications are delivered in manageable and useful to their staff to prevent overload", and this would mean doing something different to twisting the notifications into some form of pseudo shortcut work management list. If we looked at addressing this problem via the request list (or that type of view), what would that look like...? that would be worth a discussion if this indeed a problem that Service Manager does not currently address well. Gerry

@AndyHill Unfortunately we cannot, this is a change that is global I am afraid. We cannot leave individual instances on old code, the SaaS model does not work this way. This is of course why we always preview changes like this to give customers a chance to adapt/adopt. The vast majority of customers are seeing these changes as an improvement based on the feedback we have had so far. In your images above I actually think the NEW looks a lot more balanced that the OLD, to my eye at least, but I do understand its very subjective. What I can say is, if you can let us know which aspects of the new design that you would like to be able to change that you cannot currently change with the customisation options provided, we can consider extending the customisation options in the future to allow such changes. I hope that makes sense Gerry

@Martin.bowman I think it is a lot easier to say than to do in practice. The notification list is a chronologically, descending-ordered list that has infinite scroll capability. In principle, ordering this in ascending order is easy, but thats not the problem. The problem is when you are scrolled to a certain position and the list is ordered in this way, what happens to new incoming notifications, where do we display them, how do we explain to users, no its not a bug that you are not seeing new notifications, its because you have re-ordered your notifications. Then, I imagine, the next ask would be "oh, but for urgent notifications, can these be always shown at the top", and so it would go on. I think if you look at the notification features in other systems, or look at desktop notifications on Windows, mac, your phone or any of these types of systems, none of these provide a way of you looking at your notifications in oldest-first list form - there is a good reason for that. I think there is a need here, as its being asked for here, I think a conversation around what problem we are trying to solve, and less focus on the prescription "just tweaking whats mostly there", then we could probably find a way of solving the problem, for me it sounds like this is a "request list" thing, or at least a view in that area of the application would be a more logical starting point Gerry

We have now implemented baselining/version control on progressive captures. This is broadly speaking the same behaviour as you are already familiar with in the BPM/AutoTask?RunBooks etc... so its behaviour and function should be familiar. Once this is pushed to live instances (2-3 weeks) all of your existing pro-caps that are currently active will get baselines to version 1 automatically so there is nothing you need to do in order to take advantage of this feature. Once this has been rolled out, this does of course mean that after editing a pro-cap, you will have to baseline it in order to activate it.

@AlexOnTheHill Just confirmed with the dev team (and yes I should have known this without having to ask lol), this change and others are on preview.hornbill.com/yourinstance. Preview will be pushed to live on the 26th next week, so then you will see the change. If you are currently using preview instead of live as most customers seems to be currently, then this change is already there... Gerry

@AlexOnTheHill Yeah I just checked too and you are right, its not on Live for some reason, its been on beta for what seems like forever so not exactly sure why that is. I have asked and will find out... and will post back gerry

@AlexOnTheHill To be honest I thought this was on live a long time ago, I have asked the question, might be just a browser caching issue Gerry