Skip to main content

We are upgrading to FME Flow 2024 and wanting to make some improvements. As part of this we want to know if we can have a user upload workbenches to FME Flow. Then login to FME Flow with their user account, but somehow build automations, streams, apps, and scheduled jobs to run under a different user account. 

We are trying to migrate from putting the all the running automations, schedules, and other items under individual user accounts. Instead we want to assign to a departmental account. Since we have FME Flow tied into our Active Directory this will prevent any permission issues of jobs not working when an employee leaves the company and their AD account is suspended. 

I didn’t really want to have every user login to FME Flow with the departmental user account. Then we won’t keep the individual repositories for workspaces and will become a mess. I know the GUI/Web Front End as-is doesn’t support this but trying to decide what approach I could do to solve this.

My easiest thought is to have users build projects. Then create a workspace that will take a project backup and import as the departmental user, probably using the FME Flow CLI. 

Another thought is much more technical and potentially build a web page to reassign users to objects directly in FME DB. Have it generate a table based on user login with all their objects and then select which ones to reassign to run/owned by Departmental User account. 

------------------------------------------------------------------------------

I’m curious how other people have solved larger FME Flow installations and keeping individual departments separated with their other users and repositories. How they build and schedule various automations and jobs. 

Hi @ssmith_ftr,

Using Projects is an option, this would allow users to create workspaces and automations that can be imported under the departmental account using the FME Flow CLI. Another way you could manage this, is by not allowing users to create automations in a production system. Then, handle this under an admin account. This gives you more flexibility to decide when workspaces run, if resources are a concern.  

You can also use the FME Flow REST API to automatically share workspaces or automations with the departmental account / role. System events can be triggered when a workspace is uploaded, if a certain user uploads a workspace then this could be shared with the role.

In general, we recommend using roles to manage permissions rather than accounts. It just makes it easier to manage a large amount of permissions for multiple users.

 

Hi.  This older post has more info. on this topic. 

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.
Identify the User that will run workspaces within an automation | Community

cheers, hope this helps.

​@gaplin_oz I appreciate your comments on this. You seem to be one of the few that fully understands the complexities of trying to meet Cyber Security compliance requirements. Just two points. 

  1. (I think you know this one.) Whenever a running scheduled job is stopped, when restarted that job will run as the user who started, not the owner of job or whoever built the job. Doesn’t show this in GUI for Schedules, but you can use Resources to find this information.
    1. If a job is owned by one user, but technically running as a different user, because that user was last person to stop-n-restart the job, it will stop working when their AD account is disabled. Try tracking a failing job when everything shows it should be running as a different user than the user account actually being used. (Hence why we did what you explained.)
    2. Using roles doesn’t solve this as we have always found roles don't always get added to the necessary resources for every job/automation to run as any user in a role group. Roles also don't prevent the issue with a deactivated AD account stopping anything running as that user. 
  2. In terms of security audit, we did determine you can write triggers in DB, and store to separate table, to track many things. Doesn’t fix things but is nice to know who did what and when. 

Community Stats

32,030
Posts
121,647
Replies
39,655
Members

Latest FME

Terms & ConditionsCookie settingsAccessibility statement
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.