- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-12-2024 07:18 AM
1. Has anyone tried to restrict who can set flows to "Run As System User"? Is this possible? We would like to restrict the use of "Run As System User" if possible to avoid confusion when changes are made to the platform.
2. Is there a way to customize the Run As choices? Ideally, could service accounts be added as choices?
Thank you
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-14-2024 10:38 PM
It's either system or the user, those are (currently) the only options you have. And since impersonation through scripting is not a good practice, your best way to go through this, is to put some governance on flows, if this really is such a big issue at the moment. Check flows that are ready to move to production on the 'run as' and ask the creator why the system user is necessary.
Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-12-2024 07:40 AM
You can't change that, nor can you limit it. You also shouldn't want to limit it. What if someone needs a flow to update the incident task from the incident. The 'run as user who initiates session' will work if the user is an ITIL user. If it's an update that's triggered by the end user, the flow won't do a thing, since the end user has no rights to update the incident task.
There are lots of use cases to use the current user, but disabling the possibility to run as system user, will cause issues by flows just not doing what they need to do, because of this limitation.
But: in the end it's a dictionary entry: a string field on the sys_hub_flow_base table, so you can check what you want to do with the choices it is giving (adding new choices won't be possible, because the engine will not recognize those options).
Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-12-2024 09:40 AM
Thanks for replying. I understand there are situations where run as system is needed, but currently it is more of the default. When we have a variety of things running as system it can make it difficult to track changes and troubleshoot. The current thought is to have a service account associated with a process or group of processes.
I'm open to suggestions if there's a better way to manage this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-14-2024 10:38 PM
It's either system or the user, those are (currently) the only options you have. And since impersonation through scripting is not a good practice, your best way to go through this, is to put some governance on flows, if this really is such a big issue at the moment. Check flows that are ready to move to production on the 'run as' and ask the creator why the system user is necessary.
Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-15-2024 08:12 AM
Thanks again.