Actions on a request not being completed by owner when automating

[AndyHill]

I have created an analyst called SD Bot that actions certain activites automatically for our Service Desk. These are simple tasks such as adding users to a particular AD group when the ticket is authorised. 

What I have noticed though is even thought the call displays correctly as assigned to SD Bot the timeline displays the customer as performing the first few actions and then the authoriser as completing and resolving the call. 

Owner showing as SD Bot

First few actions show as completed by the request raiser.

Then once the authorisation request is completed. The call continues but now using the authoriser account to finish it out. 

I understand some tasks will show as being completed by the authoriser but the one in orange is a timeline update completed by a Hornbill Automation element after the approval stage so why does it suggest Andy Test2 did that when all he did was authorise?

Also when i check the database for one of these calls I can confirm it does show the authoriser as the resolver which messes up stats. 

[Victor]

@AndyHill is all about user context here. Has the SD Bot actually performed any of the actions recorded in the timeline? The timeline entry will record as author for the entry the user in which context the action was performed, which can be another user than request owner. The first actions, until the activity pauses, will be in the context of the request raiser. It is the request raiser who initiates the creation of the request, workflow for request and all initial automated actions on the request until the workflow pauses. All these have the request raiser as user context. Then the activity pauses for authorisation. When AndyTest performs the authorisation, we now have this user context and the authorisation and all subsequent automated actions performed by the workflow and recorded in the timeline, have AndyTest user context and is recorded as such. Even if the subsequent action(s) is an automated action (BP), it still has AndyTest as the initiator, and will use this user context. The exception here is when an action is performed by a system user and this is the case when an action does not have a huma user as the initiator. For example, a suspend node with an expiry. Upon expiry it is the system that performes the resume (specifically in this case the System BPM Manager) and actions are now recorded against this user context. User context persists throughout a set of automated actions and the user context can only change when the automation is paused and then resumed by a different user. 

Note: above, the term automated actions (or automated actions set) represent a series or set of uninterrupted actions or events performed automatically

[AndyHill]

@Victor thanks that makes perfect sesnse, is there a way to force an update within the BPM from a particular user as SD Bot isn't logged in and therefore can't update the call directly (and even if could this would defeat the automation I am going for  )

[Victor]

@AndyHill

4 hours ago, AndyHill said:

is there a way to force an update within the BPM from a particular user

Do you mean manipulating the user context? if yes, this is not possible. The user context is picked up from user session which is created when the user logs in and is stored in both browser and Hornbill back end. All actions in HB will use both to establish the user context...

What impact the user context has on your automation?

[AndyHill]

@Victor the biggest issue is for the managers producing stats. They are obviously looking to see stats for resolved by and the SD Bot doesn't really show any and other users who touched the SD Bot calls show increased resolutions even though all they may have done was raise the call. 

I have advised them that they can produce stats on who owns the call at time of resolution instead of resovled by but they want the resolved by to be accurate. 

[AndyHill]

@Victor just checked some other BPM's where i automate the resolution following authorisations and I am seeing the same thing (which I would of course based on your explanantion). Whilst the way this works makes perfect sense it kind of deters from trying to implement automation in to the system as I don't want calls to have resolvers like SYS_SECURITY.

[Victor]

@AndyHill there is little if anything that I can do in this regard. The user context, as it is, makes part of the core foundation for the security mechanism in Hornbill, I am quite confident there will be no change in the way you suggested. What is the automation supposed to do?

[AndyHill]

@Victor I have the 'automation' doing varies things now. Take the below as an example, I have created a service request for members of the Service Desk to elevate a basic user in Hornbill to a full user with the authoriser role. They raise the call through the portal and its get logged to SD Bot performs the below and resolves itself, if it encounters an error it assigns itself to my team to work out why it didn't work.

This is one of many 'mundane' tasks that I have automated, we have a big push at the moment to automate work where possible to reduce the amount of work that actually requires hands and eyes from the Service Desk. A big part of this is for directors to easily be able to see this automation which we would do by reporting on the 'Resolve By' field. I know I could create the same result by reporting on 'Owner' and 'Status' instead but I am sure a time will come when we need to report directly on the 'Resolved By' for auditing purposes. 

[AndyHill]

@Victor any further thoughts?

[Victor]

@AndyHill no idea further, sorry... perhaps worth having a conversation with a product specialist and see if there is anything that can be done in this scenario?