Martyn Houghton

@James Ainsworth Thanks for confirming that they are on the way. Cheers Martyn

The 'Get Request Information' BPM node appears to be missing the fields for 'Service Level Agreement' and 'Service Level'. We are in the process of going live with SLM and a number of our activities currently insert the flowcode value of Priority, which we are attempting to change to Service Level. I tried refreshing the nodes and also get Service Details, but that still does not provide the SLA or Service Level values as usable variables. Is there a different node I should be using? Cheers Martyn

+1

@mojahidm At the moment I do not think you can do this via a user accessible tool/process. I know this step had to be done by Hornbill for us in the initial Switch On Service but is something we will need the ability to do ourselves as well, as we merge in other Service Desks. Cheers Martyn

@Victor Appreciate the issue is being worked on, but Thursday of this week is the end of the month, like others I suspect, we will have a large volume of reports to generate for monthly reporting, so any further details in terms of timescales for this week would be reassuring. Cheers Martyn

@David Hall Our issue will be that we have multiple different 'sets' of priorities which relate to different Service Desks and Service Level Agreements within the system. Just increasing the priority up one in the list could select a priority that does not apply to the Service Desk/Service Level in questions. I think this would need to take into the account the other proposed change mention in the post below by James. In terms of re-trigger the SLM rules this would need to be configurable on an action by action basis, as for us we would not normally not want to re-trigger the SLM rules, but I can see where some people would. We used to increase the urgency of these types of cases in the SupportWorks by increasing the 'condition' field, but it might be worth looking at increasing the 'Urgency' field once the Impact/Urgency changes are implemented. Cheers Martyn

@yelyah.nodrog Hayley At the moment I do not think this is possible but is something we would use as well. Cheers Martyn

Along similar lines to @yelyah.nodrog , would it be possible to add the ability to send the reminder to the 'Team' the request is assigned too and also 'Members' linked to the request. I could also see a need in the future to be able to send the reminder to all 'Supporting Teams', but that would not be applicable to ourselves until there is the ability to add read-only supporting teams so they can view the requests but not action them, which would need to be excluded from the reminder. Cheers Martyn

Could I ask for some clarification around the Service Level Agreement escalation actions, in particular, the 'Increase Priority by 1'. How does it know what is the next priority to escalate it too as there is no direct linkage between what priorities apply to what service level agreement? Also, priority is no longer the only factor in terms of the SLA rules, so is this just updating the priority field alone? Cheers Martyn

@Victor Just to clarify your last post, does the selection have to include both a service and team selection criteria to disable the context-sensitive conditions being applied behind the scenes? If this is the case in Sam's example her original view would have satisfied point 1 and not applied the team background filter but would have applied the second background filter of services that Sam is a member of a supporting team for. However would Sam not have to be a member of the supporting team to see the requests anyway? Cheers Martyn

@James Ainsworth Thanks for the update. Cheers Martyn

@SJEaton, @Victor Do you get a different result if you change the parent 'All My Services' to say 'All My Teams' before applying the your view, as in your second screenshot you have selected by Team rather than service subscription. Cheers Martyn

@James Ainsworth @Steven Boardman Is there any update or strategy to provide free text searching for the historic updates and timeline text in the Service Manager app, as this is continuing to cause an issue with the current users of the system and proving a barrier to us rolling the platform out to other service desks within our organisation. Cheers Martyn

@SJEaton You are correct. The supporting team is the key to the permission to see the request. As I understand it you would need to have two separate services, with them being assigned to the appropriate separate supporting team to achieve this. Cheers Martyn

@James Ainsworth Thanks, I keep an eye out for it in the release notes. Cheers Martyn

@James Ainsworth At the moment we have had to assign the roles to the Portal Accounts in order to keep the system working. If you can confirm if we need to modify this or when the fix has been applied so that we can remove the workaround. Cheers Martyn

@Victor @James Ainsworth Also appears to be missing permission to h_sys_user_profile_viz as well. 2017-11-13 15:45:00Z [ERROR]:[COMMS]:[9100] Operation[apps/com.hornbill.servicemanager/Requests/bpmOperation:assignTeamOwnerRoundRobin] FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_bpm/assignTeamOwnerRoundRobin): nodeName: Get User Details; nodeId: cae66c65-e1f0-4fd8-866c-172d9988e537; At 334/1: "Uncaught EspMethodCall:invoke: Operation[session:userProfileGet] You do not have rights to access the table: h_sys_user_profile_viz" throw(e); Cheers Martyn

@Victor @James Ainsworth Also appears to be missing permission to h_sys_accounts_status as well. 2017-11-13 14:05:49Z [DEBUG]:[SYSTEM]:[1492] XMLMC Request Failed: FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_bpm/assignTeamOwnerRoundRobin): nodeName: Get User Details; nodeId: cae66c65-e1f0-4fd8-866c-172d9988e537; At 334/1: "Uncaught EspMethodCall:invoke: Operation[session:userProfileGet] You do not have rights to access the table: h_sys_accounts_status" throw(e); Cheers Martyn

@Victor @James Ainsworth We are experiencing issues with the the Round Robin node following the SM update when requests are logged via the Customer Portal. From looking at the logs the standard role 'Service Manager Authorised Desk' role needs to be updated to include permission to the 'h_sys_user_profiles' as it fails with the error below. 2017-11-13 10:13:35Z [ERROR]:[COMMS]:[7468] Operation[apps/com.hornbill.servicemanager/Requests/bpmOperation:assignTeamOwnerRoundRobin] FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_bpm/assignTeamOwnerRoundRobin): nodeName: Get User Details; nodeId: cae66c65-e1f0-4fd8-866c-172d9988e537; At 334/1: "Uncaught EspMethodCall:invoke: Operation[session:userProfileGet] You do not have rights to access the table: h_sys_user_profiles" throw(e); _fc_node_exec_cae66c65_e1f0_4fd8_866c_172d9988e537 Requests logged via the User app (i.e. manually or from emails) are not affected. Can the standard role please be updated to include the pre-requisite permission. Cheers Martyn

@Victor Thanks for the update, but it was the 'Portal Access' screen under organisation in the Live User App I was referring too rather than the portal accounts unless the admin tool screen is being extended to include an organisation based view and the flags for can cancel/organisation view? Cheers Martyn

@Victor Thanks for confirming. Cheers Martyn

@David Hall So just to confirm If I set the workflow to start a new timer on the same request, I presume this would remove the current response/resolution targets times and reset the flags for within response/fix? Cheers Martyn

@James Ainsworth Thanks for clarifying. We do wish to exclude offline users, so in our case, we will need to update the BPM to take advantage of this new option. Cheers Martyn

At the moment there is a 'Skype' field on the co-workers profile. Would it be possible to have this field added to external contact records as well? Cheers Martyn

@Chaz, @DeadMeatGF From our point of view, we would want this for the 'Skpe' contact field from the co workers screen, rather than the phone number, but that would need to be displayed in the connection part of the form as well. Cheers Martyn