Description: I have encountered a severe structural bug regarding how Native Forms handle payloads when writing to tables that have Row Owners enabled. This results in silent data loss and complete bypass of the ‘Required’ constraint on Choice Components.
Context & Setup:
-
I am using a Native Form (Add or Edit) to write data to a standard Glide Table.
-
The destination table has the Make Row Owner feature enabled on specific columns (e.g., admin_access, docente_access).
-
The Row Owner tokens (the strings granting access) are expected to be populated upon row creation (via Default Values, User Profile values, or computed columns).
-
The form contains a Choice Component pointing to a basic Text column, strictly set as Required.
Expected Behavior: Upon clicking ‘Submit’, Glide should execute a single, atomic transaction. The row should be created, the Row Owner tokens should be applied, and the Choice Component’s selected value should be saved to the database. The ‘Required’ flag should prevent any null submissions.
Actual Behavior (The Bug): Glide fails to process the insertion as an atomic transaction. This causes a race condition:
-
The row is instantly created.
-
The Row Owner security rule triggers before the entire form payload (specifically the Choice Component string) is fully committed to the database.
-
Because the Row Owner rule locks the row, the system suddenly treats the user as lacking write permissions for that specific fraction of a second.
-
The Choice Component’s data insertion is rejected by the server.
-
The UI performs an “optimistic revert” (the selected option flashes and disappears), and the database records a null value for that column.
Why this is critical:
-
The form completely ignores the Required constraint, allowing incomplete records into the database.
-
The system fails silently. There is absolutely no error message displayed to the user on the frontend, making it a nightmare to debug.
This forces developers to completely abandon Native Forms and build Custom Forms just to ensure data integrity when dealing with multiple roles/Row Owners. Please look into how Native Forms serialize and commit payloads when Row Owners are involved.
On a personal note, this is ridiculous. Fix this asap, for your own good.
Something doesn’t sound right. Everything from a form submission is one atomic action. Can you share more information about your setup and maybe some screenshots? Based on your description, I trust that you are not using any On Submit actions, right?
Thank you for the reply. After further investigation I managed to replicate the bug in other ways, and I agree that something doesnt feel right. I used both ways for actions, I have years of experience in Glide and native mobile development in general and this is an headache. I will reach out when I have more info
Hi Jeff,
I wanted to post an update on this issue, hoping to save hours of frustration for anyone who runs into this wall in the future.
After some deep diving, I realized this isn’t a frontend bug, but an intentional (and poorly documented) server-side security block in Glide, specifically causing an Optimistic UI Revert.
The Core Issue: Following basic industry standards, I built a Custom Form allowing the Admins of my app to create new users (Teachers, Parents, etc.) and assign them a role via a Choice component triggering an Add Row action. On screen, the action seemed to work perfectly, but a split second later, Glide’s server would clear the newly inserted role (leaving the cell blank or forcing the creation of another Admin).
The Reason: This block triggers if your target database column is mapped as “Role” in the app’s general settings (Settings > User Profiles). Glide heavily locks down this column at the server level to prevent privilege escalation. It seems the engine is hardcoded to accept role assignments only from:
-
Manual direct input in the Data Editor.
-
SSO tokens (SAML/OIDC) on Enterprise plans.
-
External APIs / Webhooks.
The system categorically forbids the app’s frontend UI (Custom Actions / Forms) from writing freely to that specific column, even if the user performing the action is a legitimate Admin.
The Workaround: If you are not on a Business/Enterprise plan and don’t use corporate Single Sign-On to map roles, the only way to build a functional in-app User Management dashboard is this:
-
Go to Settings > User Profiles and unmap the Role setting (set it to None).
-
Create a standard text column (e.g., custom_role) in your Users table.
-
Manage your RBAC (Role-Based Access Control) using Visibility conditions on this new column, and enforce security by applying Row Owners directly to Email columns rather than relying on Glide’s native Roles.
It would be incredibly helpful if the Glide team added a warning banner in the Custom Forms documentation. Failing an action silently via an Optimistic Revert without displaying an error log to the builder (like “Permission Denied: Role column is protected”) just creates massive confusion.
I hope this workaround helps anyone stuck in the same loop!
This is a known and documented security restriction to prevent backdoor access to unowned data. Your original question mentioned an issue with assigning a Row Owner column with a role value. There was no mention of assigning a Role column with a role value. Two very different scenarios that I could have clarified very quickly if you had answered the questions in my first reply.
In any case, a role can only be assign via client side actions or workflows if the user setting the role possess the same role during row creation. If a user does not possess the same role themselves, or the row has already been created, then the role can only be set via a server side workflow or directly through the data editor. There are several posts that cover this.
This is a trivial amount of work. If you’ve already set up the UI to set a role, then add a manual workflow and have the workflow set it instead of the app interaction workflow or button you initially setup.
it was the same issue but my first explanation was very wrong. Posts are not documentation. If it’s a so trivial limitation, why no state it in capital letters?
Shit like this happens when there’s no error log, you know.
Everything is trivial in Glide if you don’t care about quotas. I didnt ask how to do it, I’m asking why it is not clearly stated in the docs.
Sorry to sound harsh but if you actually understood the problem and the above solution you wouldnt have posted this.
It is mentioned a couple of times in the FAQ section on Roles in the Docs. Although I’ll admit that the wording is pretty terrible, hardly crystal clear, and even misleading (the docs suggest that using a Multiple Texts column is required, which is nonsense).
There used to be a specific call out in the docs advising that Roles could not be managed via the layout, but that was removed. I have no idea why 
Yes, this exactly! I could not agree more. Yeah, the solution to your problem will cost you some updates. If that’s your real issue, you might have to work out the cost of those updates to your expected use.
Depending on your use case, you might be better off spending those updates on role changes, as your workaround will likely lead to many limitations in row access (compared to using roles). The biggest one is that you’ll need a column for every email you want to give access to the row. If you aren’t sharing one row with many people, that might not be a problem. But, in a teacher/student sort of environment that’s often not the case because many people might need access to the same information, e.g., all of the students in one class need to see all of the chat records in their class but not the chats from other classes.
I’m wondering if this is referencing how the in app behavior allows a user to set a role that they have, like an admin can give an admin role but not a manager role. Perhaps the use of a Multiple Text column supports giving a user all of the roles so that they can then assign all of the roles. The last I tested this was way before the existence of the Multiple Text column so it would have to be tested to be sure.
In a word, no.
I’ve tested it.