Hornbill Staff DR

Hi Alex,  in the meantime, you may be able to restart the BPM using the "Restart Process" button located to the left of the heads-up-display. Clicking this will retry the last failed operation within the BPM. This is only visible to users who posses the "super user" or "Service Desk admin" roles. More information can be found here: https://wiki.hornbill.com/index.php/Business_Process_Designer . At the bottom of the article there is a section called: "Workflow Failure and Recovery" . Please let me know if this helps you to recover the failed workflows. Dan

Hi Alex, That's great to hear the first issue is resolved. Going back to the BPM errors, I don't believe it is a problem with the way you have configured your BPM, but the issue does reside within a particular operation that is part of your configuration. Our development team are looking into this now. Dan

Hi Alex,  it looks like you currently have two issues. 1) Application Email notifications are failing to send - this is indicated by the error: Operation[mailadmin:sharedMailboxGetInfo] The specified mailbox 'Panas Service' doesn't exist on the system 2) The BPM error shown in your screen shot above - This is referring to a failure to start the response timer. In relation to 1), please check that the value "Panas Service" is the id of an existing mailbox in Hornbill Administration > Home > System > Email > Shared Mailboxes Considering point 2), I find this quite strange because I can see a response timer exists against the request in the screen shot. This suggests there is something else performed within this BPM operation that is failing. Dan ÂÂ

Hi Sam,  I hope you are well. That's correct. This is a known design limitation that we are acutely aware of and taking steps to address. The planning has been completed therefore it is just a matter of prioritising and initiating the development work. Presently I can't provide a delivery date but this is a challenge that other Hornbill users have encountered and we recognise it as something that certainly has to be overcome. Dan

Hi Dan,  the behaviour that you mention is not something that is supported by the authorisation node. The principle of operation when it comes to the available authorisation mechanisms in Hornbill (currently the authorisation node you mention, and also the new Authorisation Action Item which allows the addition of authorisers on-the-fly) is that it only takes one individual to reject a request/change. The weighting only applies to Approvals. The explanation behind this design principle is this, if an individual feels strongly enough to reject the authorisation task, then there must be a reason for their decision. Best-practice calls for this reason to be reviewed. If you picture the worst-case scenario, where a rejection is overlooked or not given due consideration, this could lead to a Change being implemented with serious consequences to the business. In the event of a rejection, a typical Hornbill BPM approval configuration could include a task to confirm if the rejection was valid. If after review, the reason did not call for an outright rejection then the change/request would be resubmitted for authorisation. Something that may help you is new functionality that has seen the authorisation node recently expanded to incorporate "Tentative Authorisations". While this still operates on the same principle as a "reject" outcome (i.e. weightings do not apply), this allows a third outcome to the authorisation node (default value is "Tentative"). As the name of the feature may suggest, it allows a user to highlight some conditions under-which they would be happy for the change/request to proceed, and gives us the opportunity to create a different path (set of actions) in your BPM that are executed in this scenario (i.e. a branch in the BPM to define what happens in the event of a "tentative" outcome to the authorisation task). Tentative authorisations can be made available for configuration by enabling the following system setting: experimental.feature.bpm.enabletentativeauthorisations I hope that helps, Dan

Hi Sam,  regarding  "the ability to share an individual document with a Team or role", I haven't had a recent visibility of that particular change so unfortunately can't update you on any time-frame. However, I believe the underlying reason for your post today is not what this change will solve. The sharing of documents with a team or role is intended to ease the administrative burden of making individual documents available and editable to more users, rather than adding users one-by-one which is currently what we're limited to. What you are seeking today is the ability to understand what documents a user currently owns, and the ability to re-assign these to a new owner in the absence of the original individual (e.g. he/she has left). We will soon see an interface in Hornbill Administration that will allow a Super User access to address the ownership of documents in relation to users that are no longer part of your organisation. As Gerry indicates, when it comes to document ownership, the rigidness of Document Manager is there to try and instil better practices within an organisation. I hope that helps, Dan

Hi Ptobias,  thanks for your post. Generally speaking, you can approach office 365 using similar principles to an on-premise mail exchange. It is still a mail exchange, its just now hosted in the cloud. The first step in the configuration is to "point" Hornbill to office 365 rather than your on-premise mail exchange. This means updating the SMART HOST configuration via Hornbill Administration. Just like in an on-prem situation, office 365 will need to know what to do with the email that it receives from Hornbill and therefore you will need to configure office 365 to allow the relaying of messages from Hornbill onto the intended recipient. Finally, its unlikely that there will be any firewall considerations, as we are considering cloud-to-cloud communication. I hope that helps. Dan

Hi Stephen,  thanks for your post. Lyonel is right in what he is saying, you'll notice that in many areas of Hornbill we operate the principle of "Archiving" records (User Accounts etc.) rather than doing a hard delete. This is to ensure all database relationships are maintained. In the case of requests, we cancel them. It seems to me that there may also be a challenge in actually finding this request in the request-list. It sounds like it has not been assigned to a team for some reason. If you log in using the "Admin" account, navigate to the request list, you will have a menu option called "No Team Assigned". This can be found in the list of standard filter options. I've included an image shoing you where this is located. This should help you find the request, then it can be cancelled. If the request is indeed not assigned, the next step is then to try and understand why that happened. Dan

Hi @Keith , The update that you installed yesterday was Service Manager Build 994. This was released to address an issue identified in relation to the new authoriser functionality (the first item in the 993 release notes). You were presented with the 993 release notes due to an ongoing issue with the management of release notes in our build controller. As we speak today, if there is a new Application Build available and you notice that the release notes have not changed from the previous build, then it is most likely an update to patch an issue that has been identified. The Platform team continue to work on addressing the management of the release notes which will hopefully eliminate any confusion in the future. Dan

Hi Stephen,  dev have addressed the issue in the next Service Manager build which means the Known Issues list will take into account all scenarios in which a KE was closed. The approach dev are taking with this fix ensures that we don't have to make any changes to the BPM, and it can be left to close KE's automatically based on the completion of the human task. I have set the Published status of all the currently closed KE's to draft (the status to which they are set when the KE is closed manually) so they no longer appear on the Hornbill Service Portal. We can expect the next Service Manager build to be available during the week beginning 10th July and this will contain the fix described above. I hope that helps, Dan

Hi Stephen,  It was great to see you at last weeks Hornbill Insights 2017 event and thanks for posting. I took the liberty of doing a little investigation myself and I believe that there is an inconsistency between closing a KE manually, and closing a KE using the BPM operation to set the status of a ticket to closed. If its done manually, the KE record is removed from self service, if its done automatically via the BPM the KE is NOT removed. I'm waiting for confirmation of this from development but the best route could be for us to amend the BPM to wait for an analyst to manually close the KE, rather than letting the BPM do it for us. If this proves to be the best way forward, based on the recent Expert Services work we did on this, I'm happy to make the amendment for you. Dan  ÂÂ

@Keith indeed! We also have a desire for this internally, but it's one of those changes that could have a significant impact if its not delivered right. Functionally, the feature does what it says on the tin, it returns request timeline results, however it is not meeting the other QA parameters in terms of machine resource consumption (critical to the infrastructure) and speed of response (critical to the customer experience). I have no doubt that our development teams will resolve these issues but until then we must wait with bated breath! Dan ÂÂ

Hi Martyn,  the global timeline search capability was aligned to be introduced in this build but unfortunately was pulled from this build in the final round of QA due to concerns over performance. As a result, CH00128259 is not contained in build 993. The release notes in Hornbill administration are automatically generated and if anything changes at the last minute they must be manually amended, which in this case it appears that this was missed. Development continue to work on the request timeline search capability. I hope that helps clarifies things, Dan ÂÂ

Hi Steve,  the application setting servicemanager.progressiveCapture.servicedetails.catalogRequired should do the trick. Dan

Hi Chris,  it's great to hear you're preparing to migrate your calls into Hornbill. When working with the Supportworks request import utility, Business Processes will only be associated with calls that are imported with a status of "Open". Business Processes will not be associated to closed or resolved calls. As you have identified, there are various core-actions that can be carried out in Business Process such as Team assignment and email notifications. It is important to consider if associating a BPM to these imported open calls is even appropriate. Decide if all BPMs should be deactivated prior to the import or if a new BPM is required especially for these open imported calls (a new BPM can be used to great effect in helping inform customers of their new Hornbill reference number). What I mean by "appropriate" is I think what you're concerned about, i.e. if a call has been open for a number of days/weeks etc. it will be confusing to the customer if they all of a sudden get a new-call-confirmation email. To deal with this (and similar situations), you could create a BPM especially for use against these imported calls, or you could modify your existing BPM with various decision branches to by-pass or perform different operations if the call is identified as an imported one. In terms of identifying imported calls, a good method is to hard-code a custom field such as "custom q" with a value of "imported" or something similar that you can use in these BPM decision branches. Dan

Hi Stuart,  Thanks for your post. When it comes to auto-routing in Hornbill we have two functions available to us: 1) Move the message to another shared mailbox and/or folder in Hornbill 2) Initiate an operation such as Update or log a request. Neither of which would satisfy your requirement (if I have understood it correctly  ). It sounds like you need to configure a rule(s) on your mail server that either sends a copy of any received message to another mail account (so the message continues to arrive in Service Manager too) or redirects to this other mail account (which will likely mean the message will not reach Service Manager). I hope that helps. Dan

Hi Trisha,  thanks for your post. The type field needs to contain the name of the asset type to which this asset record is going to fall under. The Hornbill Asset structure can be considered a three-level hierarchy: Class Type Asset Record The Asset Classes are integral to Service Manager and drive which extended attributes are available against an asset record, therefore we don't have any power over these. Beneath an asset Class sits a number of asset types. We have full control to create and delete the types that exist beneath each Class. In the CSV we must specify the name of the type, so in your case "Smart Phone" would be the correct approach. If this isn't working, check that the "Smart Phone" type is still configured beneath the Mobile Device Asset Class as shown in the attached image. If that is all there, ensure that you are selecting the right asset class from the drop-down menu when using the CSV upload facility. We have a short video that is well worth watching at https://wiki.hornbill.com/index.php/Upload_Assets_CSV Finally, as a last resort, excel can have a habit of maintaining invisible control characters that are introduced through any copying and pasting of text between applications. This could effect the ability for Hornbill to perform a successful look-up for an asset type. Try using the excel "TRIM" and "CLEAN" functions on the contents of the type column to ensure that double spaces and control characters are removed. I hope that helps, Dan

Hi Andy,  the ticket reference you have provided as an example (SR05968) appears to have fewer zeros than I would expect. I would suggest trying with the full call reference number and see if that returns the result you are expecting. I find it can be tedious to type in all those zeros every time I need to retrieve a particular request so I tend to use an asterisk like this: SR*5968. The asterisk acts as a wildcard and means that any number of characters or numbers can appear in that location within the search term. It can save time and also allow your search to be broadened. The asterisk can be used within the search term or at the end of a search term, however we cannot place a wildcard at the beginning. Hope that helps, Dan

Hi All, I thought I would provide some additional information on the off-chance that you are faced with this situation again. The build number located by the uninstall and update buttons is the one that is taken directly from the build controller and therefore is always accurate. In terms of the release notes, there are a couple of manual steps which unfortunately leaves the opportunity for minor errors such as the one pointed out. You will also notice that the build number is included in the URL when viewing the app details: https://admin.hornbill.com/[instance_name]/appstore/live/com.hornbill.servicemanager/979/ . This ensures we always have some firm reference points when applying the latest update. Dan

Hi Paul, thanks for joining the discussion.  if the expectation is the database rights are set when a system/application right is added, this is not how it currently works. At the moment, the adding of database rights and system/application rights are separate exercises. Hopefully in the future there will be some connection between them which will make it easier for us to create custom roles, however at the moment this is what makes creating a custom role such an advanced task. Hopefully a developer with a more in depth understanding of whats possible will be able to confirm what we may see in this area. Dan

Super! It's quite a common thing that gets overlooked. When logging into the Service Portal as a user, much of what you can see and do is still dictated by the Security Roles that you posses and also the Team aspect of the Service Manager visibility model. If you log in as a Basic User (which naturally shouldn't be a member of any Support Team) the timeline content will be filtered as you would expect. Have a great weekend, Dan

Hi Sam,  I hope you are well, please could you clarify a couple of things, just to ensure I understand the current situation. I can see that you have amended the application setting and the visibility looks like it is being set correctly within the request. Can confirm the following for me: I'm assuming that you are logging in as yourself to both the live and Service URL's in order to check the timeline entries? What Team is the Request (not the task) assigned to, and are you a member of this team? Many Thanks, Dan

Thanks Sonali, I have asked development to take a look and hopefully they will be able to advise further. Dan

Hi Sonali,  thanks for your post. This may be due to some misleading behaviour in the UI. I know in the past when I've been creating custom roles it has been necessary for me to save my database rights at the end of every page. For example, if I work through the tables and make selections on pages 1, 2, and 3, then click save, only the selections I made on page 3 will actually be saved. Does this sound like what you are experiencing? Dan

Hi Sonali, Creating a custom role is a very advanced task and can involve a lot of trial-and-error and require testing to ensure that you've got it right. Is there a reason why a combination of the out of the box security roles wont suffice? Dan