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:
Only Admins can build Automation Rule Scripts and Custom Pages.
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.
This indeed might a path forward, thank you for investing the time to describe the idea so well!
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 . Run as (either explicit or implicit) is in our solutions shortlist.
Just in case, I’d like to add one more related point .
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.
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 …
I expect that Custom Pages/Apps will not have the option to Run as… another user. They are already designed to run as the logged in user (just as Buttons do) and I’m not sure what the use case is for this (apart from as a subset of this general behaviour).
We plan to allow Architects to create Custom Apps.
Yes, I agree that some scripting use cases can probably be replaced if more automation actions/features are added over time.
But in our case, we have many different internal automation directions. A lot of them are quite specific to our departments, workflows, naming rules, integrations, validation logic, data structure, etc. So I don’t think it will be possible to turn all of these cases into standard templates or native automation actions.
The main issue for us is not only “why do Architects need scripting?”, but also access control.
If scripts are needed, then even a junior automation manager currently needs very broad Admin access to build them. This means access to information across all Fibery departments, including areas that are not related to their work.
We may also have automation builders who only automate workflows for their own teams. They should not necessarily see data from other departments.
Can you provide examples. We can add your use cases to drive feature development for automations. It is more likely that we add more native capabilities to automations (or elsewhere) than we support granular permissions for scripting
Sure, I can share the general idea, although unfortunately I can’t provide exact descriptions of our internal scripts.
Some examples of the kinds of scripting use cases we have:
Form intake → task enrichment and routing
A user submits information through a form, and then a script fills many fields in the created task depending on what was submitted. The logic can vary a lot depending on the team, project, app, request type, naming rules, etc. In some cases, the script also triggers additional actions based on this context.
Uploaded files processing
A user uploads files through a form. Based on file names and metadata, the script creates additional descriptions/clarifications, fills required fields, groups or separates the uploaded files, and re-attaches them to the correct tasks or related entities.
Scheduled maintenance / workflow logic
Some scripts run on a schedule and check tasks against different combinations of conditions. For example, they can update statuses, add/remove people, change fields when related tasks are completed, or when secondary/linked work is ready.
Also, in theory, if Architects will be able to create Custom Apps , and now that webhooks are available in automations, our Architects able to move a significant part of specific automation logic into external automation systems. That could reduce the need for internal scripts.
Maybe this would be useful, if the challenges are mainly about the logic of the actions to be taken, rather than any problems with not having the right native actions needed to achieve the goal?
Is the problem here that setting up the necessary filters (condition checks) is too cumbersome?
Overall, I’m not seeing things that can’t be done with Fibery automation actions per se, but I can totally imagine that scripting feels easier when the alternative is multiple automations each with its own filtering and actions that have formula-based effects.
Indeed, perhaps offloading the more complex logic rules to an external tool (n8n?) might be an option…
To be clear, I am not trying to object to the request on principle, I am just aware that allowing scripting to run with variable access controls is something that is quite technically challenging, so I wouldn’t want to get your hopes up. If we can help with suggestions for alternatives, it might be the least-worst option
,
. 
.
, and now that webhooks 