Hornbill Staff DR

Hi Andy, the workaround has been applied to your instance. Please let me know if you continue to experience this issue. Dan

Hi Andy, we now have a workaround available that I will apply to your instance shortly. I'll post again to confirm. Thanks, Dan

Hi Ben, thanks for your post. This appears to be coming from an automated operation within the BPM. A common cause for this is that there are parameters in the node configuration that are not set. The rule of thumb when configuring any automated operation node is: The only parameters that should be set to "Automatically Pick up the value" are "RequestId" and "Access Token" All other values must have a value specified manually, or set to ignore. Let me know if that helps. Dan

Hi Graham, having reviewed the log files from the last 7 days (during which I can see one Service Manager update was performed) there was nothing untoward. This could suggest that the issue actually occurred during an earlier SM update and I would speculate that for some reason the default catalogue items failed to create, although this so far hasn't been reported on any other instance. Re-creating the catalogue item(s) will solve your issue. Thanks, Dan

When installing Service Manager it should have created some default catalogue items called "Get Help" and "Make Request". I'll review the update logs on your instance to see if there was anything unexpected during the upgrade. In the mean-time, if you configure a catalogue item under your Incident Request type called "Get Help" (or any other preferred item) and associate an appropriate workflow and BPM, you will be able to raise calls. Thanks, Dan

Hi Graham, thanks for your post. Do you have any catalogue items defined within your Service Configuration? If these have been deleted then this could be the cause of your issue. Dan

Hi Gareth, thanks for your post. The first relates to notifications to team members and also to the individual owner of the request. It is possible to configure the method (email or system) these notifications are delivered. More information can be found here: https://wiki.hornbill.com/index.php/Notifications With regards to your second point, this refers to the request list "Views". When configuring a new view, previously only your team membership was being taken into account which meant that you would not see requests belonging to other services that your team supported so it would be showing you fewer requests. The fix ensures that now both your team membership and requests against services that your team supports are now returned in the request list when a view is applied. Information on views can be found here: https://wiki.hornbill.com/index.php/Request_List_Views Hope that helps, Dan

Hi Sam, thanks for you post. You have correctly identified that we as yet do not promote a Hornbill Portal for our customers. Our chosen support model is first and foremost aimed at building a thriving Community where, just like on the Hornbill Platform, subscribers can discuss and contribute to various Hornbill topics. The second objective was to break down barriers and enable our customers to quickly and easily raise issues with our Application Support Team without even having to log in to a portal each time and having to remember log in credentials. This is now available to do via our web form: https://www.hornbill.com/request/ The introduction of our Portal is on the agenda, but at present I can't be more specific than that. Dan

Hi Lee, when creating a view, as you know you can simply define a single condition e.g. "Status is CLOSED". What you don't see, is that the views are hard-coded to consider your Team membership i.e. the view you create with the single condition specified here, will actually be performing the following: Get Requests WHERE Status = Closed AND Team Id = My/Team/A AND Team Id = My/Team/B AND Team Id = ........... and so on. Therefore at the moment, if you are not a member of a team to which a request belongs then this will not be returned in the request list view..... but please read on below: As James also says, this should also take into account the Teams that Support each Service against which a request is logged. Therefore if you are a member of a team that supports a number of Services, in your request view you will be able to see requests assigned to other teams by proxy of a Service i.e. as long as the team that you are a member of supports the service against which one of these requests is raised. I hope that makes sense, it does take a little bit of thinking about. Also, the last part regarding the services will be true when a defect is addressed in SM 2.24 (FIX: Services and teams are both respected when filtering the request list PM00138573). Until this fix is released, it will be necessary to specify each Service you want to return in a Condition i.e. "Service is Service A" etc. I hope that helps, Let me know how you get on. Dan

Hi Chris, thanks for your post. I'll feed this back to development for future consideration. Dan

Hi Gareth, thanks for your post. Would you be able to provide a bit more detail? Thanks, Dan

Hi All, just looking back at your initial post Chris, to follow on from Victor's response information on team/analyst notifications can be found on the following wiki page: https://wiki.hornbil...p/Notifications . This will negate much of the need to handle internal notifications via BPM. Speaking more generally on the topic of assignment, my advice would be to handle the initial assignment of a request within BPM. I usually configure this automated operation as the very first node as it is important to give the request a home (we don't want things getting lost). It should be possible to take this approach with almost all requests as you will know which teams are best positioned/experienced to deal with particular call types within your organisation (or typically all calls will be triaged by a first line team of sorts before being manually channelled to more specialist teams. The new request catalogue functionality introduced in SM2.22.x, makes this approach even more viable through defining and implementing a Service Catalogue. It is then possible to configure a BPM per catalogue item. Thanks, Dan

Hi Nasim, in the mean-time, it should be possible to index these records through the Hornbill Administration UI. When logged in with the Admin User Account, in the context of Instance Configuration > Data > Index Storage, check the "Entity" index storage and from the small drop down menu on the top right select "re-index selected", and "New". This should only be performed out of hours in order to avoid any potential impact to other users currently logged in. Let me know if that helps. Dan

I can inform you that the ESP Expression functionality is now available. Full details along with a specific example can be found at the following wiki link: https://wiki.hornbil...plate_Variables Thanks, Dan

Hi Martyn, thanks for your post. The portal associations for contacts are carried out in Hornbill Administration. In the context of Instance configuration > Manage Portals > Guest Accounts. Selecting an individual contact will display their details over towards the right of the screen, here there is also a small arrow that when clicked will expose a menu containing the items needed to make the portal association. Contacts need to be associated to the "Customer" Portal. Thanks, Dan

Hi Marion, If you do not wish to present the "Request Details" form (used to capture the Summary and Description) in your Progressive Capture flows, it is possible to populate these fields using an Automated Task (the Blue-coloured Node) in your BPM workflow. After placing a new Automated Task node on the BPM design canvas, configure as follows: Scope = Entity Entity = Requests Type = Update Request Task = Details This operation will then give you the option to specify some content to put in your Summary field. Please remember that when configuring the node, the "Request Id" field must be left to automatically pick up the value and the other Options must have a value specified against them. With this approach, all requests that have the BPM associated will contain the same summary content, so I would suggest perhaps including a Human task that prompts the analyst to add more specific detail to the summary and/or description based on the information the customer has supplied (stored in the Questions section). The full range of BPM operations can be found at: https://wiki.hornbil...rocess_Workflow I hope that helps, Dan

Hi Kelvin, due to the differentiation between internal and external end users (Basic Users and Contacts) the customer of a request can either be a Co-Worker or a Contact. This means there is an additional consideration when it comes to configuring your email templates. For Co Workers (Basic users and Full Application Users fall under this umbrella) I would use one of the following variables: {{Customer Coworker.H_name}} or {{Customer Coworker.H_first_name}} For contacts I would utilise {{Customer Contact.H_firstname}} and {{Customer Contact.H_lastname}} In an implementation where both customer types are encountered, we will shortly have available the use of ESP Expressions whereby we will be able to specify both Contact and Co-worker variables and surround them with an expression which will omit one or the other depending on whether a user-defined condition is met or not met. The use of an ESP expression will ensure the template is always well formed. The alternative is to dispose of the line where you address the recipient. A message can still be friendly, polite, and professional without the need to address the individual personally. Many Thanks, Dan

Hi Kelvin, thanks for your post. Custom buttons were originally designed to allow the user to a specified URL, but also allow the URL to be constructed based on some Service Manager variables that are provided e.g. Summary, Request reference etc. Once configured, the buttons are available to all users. Thanks, Dan

Hi Chris, thanks for your post. Currently Hornbill does not offer a customer survey module/functionality as such. There is a rudimentary feedback facility presented to end users via the Portals. When their request is in a Resolved state the Customer has an option to leave a start-rating and a supporting comment before having the ability to close the call themselves or indicate that there is still an issue, in which case clicking the corresponding button will set the request back into an Open state. Thanks, Dan

Hi Chris, thanks for your post. Unfortunately, as you've correctly identified, there isn't an option to add all Users to a Service. The subscriptions would typically be performed on a Group by Group basis (Company, Departments, Teams, etc). It would appear that we would benefit from a method to add multiple users to a Group to ensure the Group structure can be more easily maintained, which would assist with your situation. Thanks, Dan

Hi Ben, thanks for your post. This sounds like a standard error message but I wouldn't normally expect it when a SSO Profile is enabled. I'd start by asking/performing some basics: Do you experience this with all Users? Does this happen on all machines? Does clearing your browser cache and cookies change the situation? Thanks, Dan

Hi Marion, thanks for your post. Currently there is no relationship between the Custom Fields created using the form designer in the service configuration and the Progressive Capture Custom Forms. The information gathered using the Progressive Capture custom forms is stored in the "Questions" section of a request where it is available to the analyst (see attached image). It would be good to further understand your specific need for the information gathered via progressive capture to appear in the custom fields created in the Form designer. Would you be able to provide further context here? Thanks, Dan

Hi Ben, thanks for your post. From the information given there are potentially two issues here. Firstly, even though SSO is enabled within the Hornbill Application, at times it will be necessary to ensure your browser of choice is configured to "allow login using the current username and password". There is various information regarding this available online. Using a search term such as "enabling automatic SSO in chrome" will yield some good results. Secondly, as James has indicated, the error you are seeing is suggesting that the clocks on the instance and your iDP are out of sync. There is a time tolerance when it comes to validating a SAML assertion to ensure that it is recent, by default Hornbill allows +/- 60 seconds. Anything that falls outside that tolerance will fail to validate. There is a setting that controls the size of this tolerance, and it is found in Hornbill Administration in the context of instance configuration > settings > advanced: security.saml.timeSkewCompensation I hope that helps but please let us know if you need more information. Thanks Dan

Hi Kelvin, thanks for letting us know. Your approach in using the "Wait for Request Owner" is sound. If the request does not have an owner, and you wish to suspend the workflow until an owner is assigned, then this is the operation to use. The other operation "Wait for New Request Owner" is used in the scenario when the request already has an owner, but you want to suspend the workflow until a different agent takes ownership of that request. Thanks again for posting back. Dan

No Problem, Happy to help