It was only part of a discussion, but I want to raise it as an issue. Especially in a larger installation, where many people are involved and have different access rights, this issue causes support effort.
People have rights to admin applications and automations in their own workspaces. However, some automations are connected to apps they don’t have access to. But there is no warning or locking mechanism.
Editing the automation shouldn’t be allowed to users, which don’t have all necessary rights for all involved apps. Currently this breaks the automation, which we think is a bug. Especially as its not obvious - saving appears to be working, but automations start to fail from now.
You know, I just ran into this internally yesterday. We have two different seats. One for doing all of the automation and then I have my regular seat. Sometimes I save over automations and accidentally break them while using my personal account.
I believe that the automation holds on to the permissions from the last user who saves.
I’m not sure of the best way to handle this but I figured it might be worth sharing in hopes it helps to move us closer to a solution.
@dirk_s@1F2Ns, yes this is indeed a problem that still needs to be optimized and that we have already included in the roadmap.
On the one hand, the automations must automatically receive the extension of permissions from the last saver without having to save them again. The loss of permissions, however, should only occur when saving again (otherwise automations will break if the last saver loses permissions).
For overwriting, a warning modal would probably be a good compromise. Complete locking often leads to new problems, such as automations that can only be edited by a very small number of users because the last saver had very high permissions.
Not sure I understand completely: This means, as long as fields with higher required access in an automation remain untouched, the current user can save the flow without destroying it?
That sounds like a smart approach. Does this means:
without proper rights, user can’t create a calculation with a field / record without access - true,
but user can still save the flow changed it elsewhere?
The warning of overwriting should probably state which access right is missing.