Make Event run as the User that generated it

[Jon Ulrich]

I am working an issue where the system is timing out when an approver is approving several records at once form approval list view.

Admittedly, the records the approvals are for have large workflows that continue when it is approved.

I see this issue as a problem of the system running the approvals synchronously from the user clicking approve through to the workflow doing all it needs to do.

My solution I have been attempting is to run the approvals run asynchronously via an event that runs a script action.

This is working great to make the system free up the user's session while it goes and does all the stuff on the back end, but I have run into a new issue.

Because the system is chaining the approval state via the script action, everything reflects the approval as being done by the system.

Does anyone know of a way I can have the script action run as the user who triggered the event?

[LaurentChicoine]

Hi Jonathan,

To have your script action runned by the user who generated the event, you could try to use gs.getSession().impersonate('sys_id_of_user');

To have the sys_id of the user, pass it as a parameter or query the user using event.sys_created_by

Not sure how the system will handle concurrent transaction or post transaction as I don't know how to end the impersonation. I did not have much time to look at it but I think it's worth a try.

Otherwaise, you can set autoSysFields(false) and manually set the update system fields using event.sys_created_on and event.sys_created_by to set the update. But that will require to apply that on every record that gets updated which may not be possible if the update generates other updates via workflow or business rules.

[Jon Ulrich]

Its definitely something to try.

I'll give it a whirl and let you know how it turns out.

[matt_willis]

Hey Jonathan,

Just stumbled into your post while looking for a solution to a "run as" issue of my own.

The way I solve your issue is by placing a 1 second timer in the workflow immediately following the approval activity. This essentially ends the approver's involvement in the workflow, and returns control back to the user session, without having to wait for subsequent steps in the workflow.

The 1-second timer executes, and then the "system" user continues to execute the workflow activities independently of a user session.