SYS_SIS_SERVICE - Automated closure.

[AndyHill]

I have configured one of our BPM's to automate the closure of a request when an ITOM operation completes. The whole process works fine but when you run a report on the team to show resolves/closures the request does not display. 

If I run a report on the the person i know was the owner of the call it displays the resolve under the account SYS_SIS_SERVICE as below. 

Is there away to get this to correctly display as the owner. 

 

[Victor]

@AndyHill this is correct. The resolution happened in SYS_SIS user context (system user used by ITOM). Therefore the user set as the one who resolved it is SYS_SIS. It wasn't really Mapi who resolved it, was ITOM.

[AndyHill]

@Victor makes sense but is there any way to correct that for reporting purposes? The system doesn't recognise SYS_SIS_Service as a user for any views either. The Service Desk supervisor needs to be able to view his teams resolves regardless of whether the system made the final resolution or the service desk analyst did. At the very least he needs to see the SYS_SIS_Service closures when reviewing the closures performed by the team.

[Steve Giller]

@AndyHill

First thing that springs to mind is to follow the Resolution node with an Update Custom Fields node, populate one with the current Owner and report on that. Would that achieve your goal?

[Victor]

@AndyHill there is nothing to correct... correcting the data in the way that you mean means breaking it really as the user context is no longer accurate...

Is the supervisor list actually accurate if we include requests resolved by ITOM since it wasn’t the analyst who resolved it, was an automation...

Could be that I don’t have the full picture here so I might not understand this fully...

[AndyHill]

@Steve Giller I would hate to have to update all by BPM's with that but i imagine that would work. 

UPDATE: It appears this request is now showing correctly under the analyst. It may be because the call has now gone from Resolved to Closed. I will do some further testing. 

We have also had the latest batch of updates since this problem was spotted. 

[Victor]

Depends in what context was closed... again might be that I don’t understand this fully...