Gerry

Can you clarify what you mean by "The Data Warehouse"? Are you referring to a function in Hornbill or another tool? perhaps a screenshot? Gerry

@aw2215 Nasim makes a good point, if you are using SSO, I believe most identity providers will also have controls for this sort of thing, so even if the federated service was public there are most likely administrative controls to restrict access to the service based on IP or other security policy restrictions. Good suggestion @nasimg Gerry

Hi Andy, There are no controls to enable this currently. We have been increasingly asked for this capability and we are looking at adding some IP address management and restriction capabilities to an upcoming enterprise edition of the platform. However, there are problems with restricting by IP address that means its not really fool-proof. Without going into chapter and verse, our UI's are served from web servers which we of course control, but we front-end our service using a Caching CDN (Cloudflare) which we have no control over, so we have no way of selectively blocking access to our UI endpoints. (Please note.... no data flows through the cloud-flare network, only the UI/front end web pages) The user app, portals and mobile devices all ultimately hit the same Hornbill API endpoint, this is where we would have any such controls enforced. This means that enabling IP address restrictions you would be severely disabling Hornbill's functionality. DHCP is so prevalent there would be no realistic way of not blocking mobile devices using IP addresses, which is why we use a secure pairing scheme, unless you would only ever want the mobile device to work when you are in your own LAN environment with WiFi enabled. In terms of the portal, the same thing, it would only work via VPN, so if you had a home working user who needed to report a problem, say a password reset request, they would no longer have any way to access your portal because they are not emanating from an IP address you have blocked. However, despite all of that both on the Apple and Google networks, notifications are sent via their respective gateways, so even if you did block the IP address of the phone, they would still receive notifications. So blocking by IP only has a very specific set of use cases is the main point. So perhaps I can answer your question with another question? What is it you are trying to achieve? or maybe better put what is the business requirement you are trying to meet? Gerry

Ok that sounds great, let me know what they say. Maybe we should be building am asset discovery tool again. Gerry

Hi Dan, OK that all makes sense now, I think I understand what you are trying to achieve. Now I know we have integrations with SNOW already, but I have a feeling thats for an on-prem deployment where we were able to pull from the database. For SNOW in the cloud I am not sure how that would work as I am not sure as a customer you have direct access to the database in that deployment model - perhaps thats a question you could pose to SNOW in your communications with them? I think we would be happy to look at creating an integration for you if we have access to the database, not sure how it would work if we cannot get the database access, possibly some form of automated export/import type arrangement. Much of this depends on what we can do with SNOW its self. Gerry

Hi Dan, So you are currently using SNOW to manage your software licenses and thats doing what you need. Are you trying to bring data in from your software license management solution as well? I am not sure you have said that but just wanted to clarify. I think you are saying you are looking at SNOW as a tool to discover your assets (by that I think you mean your hardware assets?) such as computers, servers etc... ? and then create visibility of the said assets in Hornbill Service Manager? Setting SNOW aside for a moment, can I we drill down a little on the specific data you want to get into Service Manager, do you have any sense of that right now? I am trying to understand scope here, Is it your desktops, notebooks, servers etc... or does the scope extend to mobile devices? or any other? "to have a real time asset management solution in place to more accurately monitor hardware" , and specifically "to more accurately monitor hardware" am I interpreting that as to know more about what assets you have, accurately monitor means? know where they are? know what configuration they are? know if they are being used? I am assuming the purpose of brining them into Hornbill is not for reporting, its more related to enabling your team to log requests against said assets? I sound like I am asking loads of difficult questions don't I... just trying to understand what you need to achieve so I can give you the best direction. [edit] you mentioned you have not bought SNOW yet, what deployment method are you considering... is it cloud based or on-premise deployment - this would be very helpful to know Gerry

Hi Dan, I will ask the question internally, I suspect our asset import tool might already work for this. Can I clarify,.... * are you using SNOW on-premise or in the cloud? * [We would need to to update our asset database with hardware details, user login details etc, as close to real time as possible, and possibly software on each device as well.] I think you are saying you would like to achieve one-way replication of data from SNOW to Hornbill Assets as close to real time as possible? Can you quantify "as close to real time as possible" are we talking minues, hours, days etc...? * Can you provide any screen shots of the type of data you want to bring across please? Thanks, Gerry [edit] I was also mean to say this is in the wrong forum, this type of integration does not fall under the iBridge, I will re-locate the post to the general integrations forum.

Hi Dan, Twillow I know for sure, not sure about others, I think we have a couple in iBridge. Let me know what IVR you are using and we can take a look and see whats possible. Gerry

Dan, Anything that has some form of Web API. Twillo is a good platform for this sort of stuff and we have integrations in iBridge built for that already. Your own internal phone system may well have IVR capability so worth a look for sure but in my experience the "telephone system provided IVR;s" tend to be over-complicated and outrageously expensive with feature keys required for almost every single feature. Modern VOIP/Communications platforms like Twillo buck this trend and make way for innovation. (I do not work for, or have shares in Twillow - just saying) Gerry

Hi Dan, I understand the thing about SSO but there is still a lot that can be achieved with a mobile smartphone or IVR, fully automated this means your users will have access "right now" 24x7 and of course you could eliminate taking calls for this completely. One example would be they call your service desk and are prompted with a voice response, press 1 for Password Reset type thing. In there they could be asked for a PIN number (basically a secondary security question) and on the back of that they could be "text messaged" a temporary password which when logging in they would have to change their password. https://www.twilio.com/use-cases/contact-center/ivr/build Another possibility along the same sort of lines would be a mobile app that uses the identity of their mobile phone coupled with a security question such as a PIN number to effect an automated NT password reset. There are lots of ways of automating it I believe. Gerry

@Dan Munns "a lot of work has gone (is going?) into pushing the portal as the best thing for the user since dress down Fridays" superb... I think you have it spot on, any business justification (such as for audit purposed) that gets your users on the portal will ultimately be better for your customers and you, frees your team up to deliver higher value work. Email is the devil when it comes to sucking up time for IT ... its always easier for people who want help from IT, just fire an email and make their problem IT's problem, but allowing that cuts off every possible avenue you have as a service provider to improve the service you deliver - kudos for getting those numbers. You also said, "The above chart is over a 6 month period from July to Dec 2017. Looking at our monthly stats almost (sometimes over) half of all our calls are password resets taken over the phone " so how can we help you automate that, it would be a big win for you guys if we can right? Gerry

@Lyonel lol "if emails were down for 2 days, most people in the IT department would get the sack! that's why we moved to Office 365" I hear your pain, not every organisation is quite ready to let go of their beloved email treasure I will let one of our SM product team pick up on the FAQ requirement and respond with something that does not include get rid of email... thanks for the clarification Gerry

If email was down for two days what would happen? Anyone that can send email would reasonably have access to a browser, even if thats on their phone. In my experience, there is always a way of forcing a transition from email to a self-service portal, your organisation just needs the conviction to do it. I wont profess to understand the organisational or political dynamics of each organisation but there is certainly no technical reason in todays world not to abandon email in favour of a portal/self-service, thats a choice each organisation makes (or not) Gerry

Its been my experience that if you remove email as a channel for logging support requests, users will go to a portal instead. The problem with email is exactly what you say, users like it because its easy for "them" but if you force the issue it is almost always ultimately better for both the customer and the service desk to work in the portal. I think its a leadership challenge as much as it is a product/feature challenge Gerry

All, One of our devs has had a look at this and has fixed it. Its currently on our dev stream and will make it through the pipeline over the next 72 hours or so. Gerry

Hi Tom, I have asked the question internally and we are having a look. I cannot promise anything because the data model is such that it might be difficult without substantially changing the behaviour of the tasks. We will see, I will post when I have an update. Gerry

+1 me too... ok I will see what we can do about it Gerry

Hi Tom, The tasks where never implemented to behave like a "miniature call", they are really designed to be atomic human actions and so the notion of ownership by a group is not something the underlying data model would support. In Service Manager tasks are associated with requests, and requests can be assigned to groups, or individual users. Perhaps rather than being specific about a functional behaviour can you expand more on what you are actually trying to achieve from a business/operational perspective? Gerry

Hi Tom, I cannot see any reason why not, I am not entirely sure why its not already there, I will raise the question and get it sorted if we can. Gerry

I expect it would be code, rather than the display name Gerry

Martyn, This can be done as Trevor says above, but via libraries. Although one layer of indirection in terms of sharing you get a lot more flexibility using this approach. You can share libraries with roles, groups or individual users. So the idea would be, define your libraries, share your libraries with the teams as appropriate for your structure, then share documents into libraries. Gerry

Martyn, Is that for regulatory or commercial reasons? if the former, would the same problem not apply to Hornbill? Gerry

Martyn, Not sure I entirely understand, could you expand on your use case here? as make simple lists less simple might not be the best solution to your specific needs. Gerry

Hi Keith, Thats a good point and one I think I can answer. First of all, a bit of background for the benefit of others who might read this also. Hornbill has two portals that are fundamentally different, they are called "Customer" and "Service", the "Customer Portal" as the name suggests is for access by external customers (contacts in Hornbill speak), setting the customer aside, the remainder of this content relates to the "Service" portal which is what is of relevance. In the case of the "Service Portal" our platform includes the notion of a "basic user". This type of user is in fact a collaboration user with very restricted system access designed to allow access to limited parts of the system in order to facilitate a self-service capability without the need to be a subscribed collaboration user. However, it is possible for a full collaboration user to also log into the service portal simply because they are the same type of user account with more rights. "In honesty I hadn't considered that having a collaboration license might solve the problem. Essentially yes I am asking for this functionality in the portal, but that wasn't from a perspective of cost avoidance, though of course that is a consideration." I had not made that assumption, I was just checking to see if I was reading correctly what you are looking to achieve. The point about confusion is absolutely valid and I agree 100% with you that this would be a problem. Before I get onto that, lets talk a little bit about the BPM and Tasks on the Platform. Although many of our customers see BPM as an integral part of our Service Management application, the reality is the SM application has been built on top of the BPM. The BPM as a stand-alone feature is a very powerful business process automation and orchestration tool. It is designed to support exactly the type of use case you have here. If you need a structured, repeatable and auditable business process for compliance then the business process capabilities of Hornbill are every bit as good, if not better than the likes of dedicated tools like Oracle BPM, Tibco BPM, Bizagi BPM etc... Hornbill as a business process automation solution is actually a very cost-effective solution because with an application like SM to manage and initiate running processes, the cost of a collaboration user is just a few pounds/month compared with the other dedicated BPM solutions which can run $25 to $75/user/month. If you have people that naturally fall outside of a typical SM user but still need to be in the process automation loop then I would urge you to think about Hornbill as a BPM tool first and foremost with SM built on top of that capability. So back to the Portal then. We have already established that a collaboration user can log into the "service portal" with their collaboration user account and everything would work. You are highlighting a dichotomy we have had since we first implemented Service Manager on the platform. We chose to create a portal because we felt that basic users would benefit from a consumer-like presentation, this was an alternative to giving basic users a limited functional experience in the normal user app. The normal user application has been focused more towards power users rather than end users and the resultant evolution of the portal has created that gap. Your particular requirement can be solved in one of two ways. * We provide basic tasks functionality in the Service Portal to Collaboration users when they log in. This is probably the best short term solution as we could do this quickly for you if this is important. * We change our service portal strategy to replace the Service Portal with an alternative experience in the user app, providing a more consumer-like interface presented within the user app while still providing the power user capabilities where needed. This is probably the best long term solution as the above alternative leads to duplication of functionality and creating second-class citizens for some users. In either case your task users can avail of the Hornbill mobile app which is very geared for easy task viewing and completions. As I said before this has been an ongoing debate amongst our product teams internally and one that we need to bring to a close at some point. The other point you made is that of cost. This does come up a lot, in particular in relation to Service Manager where the IT team sees some approvers as non-customers, don't want those people exposed to the power user interface and don't want to pay for collaboration subscriptions. Our guiding principle for subscriptions and functional boarders comes from the basic premise (in the context of Service Manage) that if an individual is participating in the act of "providing service" then they should be licensed in some way, in the word of Hornbill this means they need to be a "platform" user (as opposed to a basic user or guest), we call these types of users Collaboration Users. Conversely, if the person is only in receipt of service that is being provided then we consider these users a basic or contact user, and no subscription is required. For your requirement I would a suggest that most satisfactory approach would be to use Hornbill as your BPM tool. Your team (as they do today) are the power users who control and manage all of the requests and processes they manage, but all others that are orchestrated by, and participate in workflows would be Collaboration Users. There is a cost involved that you have perhaps not budgeted for but I would encourage you to look at Hornbill as a BPM tool and not simply as an SM tool in this context. Any comparison to other BPM tools, or even task management tools we might otherwise integrate with would be quite a lot more expensive than simply using Hornbill Collaboration users and task management. I hope this gives you a perspective, will be very happy to discuss further with you. Gerry

Under the hood the activity streams do support multiple levels of visibility so its possible. However, the use of the Activity stream from the Service Manager perspective is limited i believe to customer and team so this is something someone in the SM dev team would need to pick up and comment on. @James Ainsworth ? Gerry