Limit a user's Executing Requests on Behalf of Others to a list of approved service users.

-I do not think this functionality is active in assyst but better to log an incident to investigate this further.

-I will do a test to check this behavior is achievable by using CSG’s. If some one is trying to execute on behalf of request using user A which is in restricted CSG for the actioning user, may be you can achieve your requirement 

- If you are using “on behalf of” function through ETM, then you can use “No value when” field in the data mapper with an expression to check something on assyst user form specific for admin accounts
For example :
you can add all the admin accounts to one service department (either primary or secondary), 
then build an expression to check on behalf of user is in that svd, if yes then return true. So the etm will stop processing further in that data mapper.

Thank you very much for the reply.

I have since logged a support request as recommended (448492).

I had not thought about the ETM angle, while not exactly what i need, it is intriguing.
The problem I’m facing is whether to enable non admin assyst users to use onBehalfOfUser, and this then cause the need to think about privilege escalations as some users or bad actors could be tempted to use this power with a highly privileged user, such as the ETM user.  

The cause of this line of questions is due to the desire to let some integration users use onBehalfOfUser to better indicate what integration is performing an action, modification of a resource, or other changes in the application without also having to force them to set up multiple separate Windows service accounts, etc. This would allow for similar distinction for these integration users as can be done using ETM. 

As it stands, this seems not possible due to the possibility of massive privilege escalations if a user can’t be locked down to only being allowed to act on behalf of an admin-selected list of “dummy Assyst users.”

I will be keeping this thread open until the ticket is resolved; however, unless there is something else I've missed, the onBehalfOfUser functionality seems best kept under lock and key until an eventual enhancement is implemented.