Run Automation Rule Scripts and Custom Pages as a specific user

Ideas & Features
1

Hi Fibery team :slightly_smiling_face: ,

I’d like to suggest a simple permission model for Automation Rule Scripts and Custom Pages / Future Apps.

The idea is to add a Run as setting to these features.

Field for example:

Run as: [User]

Default behavior:

  • If an Architect creates an Automation Rule Script or Custom Page, Run as is automatically set to this Architect.

  • Architects cannot change this field.

  • The script/page uses this user’s current permissions every time it runs or accesses Fibery data.

  • If this user does not have access to a Space, Database, Field, or Entity, the script/page does not have access either.

  • If the user later loses access or is deactivated, the script/page should stop working and Admins could receive an alert, similar to failed automation alerts.

Only Admins should be able to change the Run as user.

So an Admin could choose:

  • themselves;

  • another user;

  • or a technical user/service account created specifically for automation.

This would solve a practical problem.

Right now, if a team has Architects or junior automation builders, there are two bad options:

  1. Only Admins can build Automation Rule Scripts and Custom Pages.

  2. Give these builders Admin access, which also gives them access to sensitive data across the whole workspace: finance, HR, management spaces, private projects, etc.

With Run as, Architects could safely build scripts and custom pages for their own departments, but only within the data they already have access to. They would not need full Admin rights and would not get access to sensitive workspace data.

For Custom Pages / future Apps, this would also make the data-access model clearer: the page/app should not become a way to bypass Fibery permissions. It should read/write Fibery data only under the permissions of the selected Run as user.

We already use technical users/service accounts as a workaround for some automation cases. It would be useful if Fibery supported this more explicitly.

As an additional idea, Admins could be allowed to create a small number (1-3) of special Automation Identities. These would be non-human users used only for running scripts, custom pages, and future apps with controlled permissions.

This would keep the model simple:

  • Architects can build, but only under their own permissions.

  • Admins can decide when something should run as another user or technical account.

  • Scripts and custom pages do not keep access if the execution user loses permissions.

  • Sensitive workspace data remains protected.

Thank you!

2

This indeed might a path forward, thank you for investing the time to describe the idea so well! :heart_hands:

In terms of our plans, we’ll start with addressing this bit:

The repercussions are far wider than automations, so we’d like to introduce a way to hide certain sensitive data from Admins.

It’s likely that once we introduce such an option, we’ll have to change how permissions are checked in automations, whether we want it or not :sweat_smile:. Run as (either explicit or implicit) is in our solutions shortlist.

3

Great, thank you very much! :+1:

4

Just in case, I’d like to add one more related point :face_without_mouth: .

Claude via MCP gives less accurate answers for Fibery data than Fibery’s internal AI, so it would be great if the same sensitive-data restrictions could also apply to the internal Fibery AI.

I mean not cases where a user directly asks AI to open a sensitive database, but the theoretical access of AI itself to open a sensitive database or looking into it.

So sensitive databases can be hidden/restricted from Fibery AI. So that we can clearly and precisely show our management and security team that AI works inside our workspace, but it has no access to these databases in any form or in any way.

5

It might be worth getting into some discussion about why architects are having to use scripting. Perhaps you want to add your input to the discussion here:
https://community.fibery.io/n/feedback-needed-scripts-in-automations-that-shouldnt-be-scripts/6560
And potentially the need will diminish if we implement some of these requests…
I can see that you previously mentioned webhooks needing scripts, which is thankfully no longer the case, but perhaps there are other things we should look into …