Identify the User that will run workspaces within an automation

I can confirm that what you're seeing is also happening in FME Flow 2023

And there's no way to see that the automation was last edited by someone other than the owner?

No, it's still listed as owned by the original creator of the automation.

The only thing you can do is retrieve the username and sourceName from the completed job via the Rest API, then retrieve the full list of automations, match that with the sourceName to get the owner of the automation and see if that is different from the job's username.

As @Hans van der Maarel​ suggested there is currently no way to differentiate who last edited an automation vs. who created it apart from using the Rest API and comparing the values.

This would be a great enhancement though, and I recommend filing an Idea to garner community support! Many of our features and enhancements come from these ideas!

So if the user that last edited an FME automation is removed, who is the automation run as? Would it fail?

It fails! There's an error in the automation's log that says that the original (now deleted) user does not have run permission for the repository the workspace is coming from.

If I then recreate that user (same username and permissions) the automation magically works just fine again.

When deleting that user I did specifcy that ownership of all items would have to be transferred to another account, but apparently this does not happen. Also, at no point is it visible that that user has anything to do with the automation.

Ouch!

Yes! Presumably this would also apply in case the user is still present but with reduced permissions.

@katebrillinger​ I think a bug report is in order here, can you file one? The crux of the issue seems to be that the last user to edit an automation is the one that is used to run any workspaces in the automation, but other than the job history page there is no indication that this is the case. Removing the user or changing permissions results in errors.

Yes I will definitely dig into this more and get something filed as I am noticing the same behaviour on my end!

I have filed this with our team for their review. For internal reference purposes, the ticket is [FMEFLOW-21301]

Hi.
I’m a late contributer to this topic and I’ve also posted on related topic FME Flow and scheduling jobs as alternate user account | Community
This is an issue for us as to set the “Run As” we have to logon with an inbuilt account and edit the automation so it runs as this inbuilt account (which also owns our repositories, automations etc).
This is undesirable as it doesn’t meet our Cyber Security posture of only administering systems with our individual credentials.

Please advise status of [FMEFLOW-21301]. We’re FME Flow 2024.1.

Thanks from Australia.
 

Hello , 

FMEFLOW-21301 was resolved and tested on FME Flow 2024.1 build 24561. This ticket addresses the automation behavior during ownership transfer and user removal, ensuring automations disable correctly and continue functioning under new ownership as addressed, resolving the bug brought up by redgeographics in older comments here.

 If you are encountering the same issue in a later version/build , please reach out to us by submitting a support case.