# CRITICAL BUG: Race condition between Native Forms, Choice Components, and Row Owners causes silent data loss (bypassing 'Required' flag) **URL:** \ **Category:** Report a Bug\ **Created:** [August 4, 2026, 4:26pm UTC](https://community.glideapps.com/t/critical-bug-race-condition-between-native-forms-choice-components-and-row-owners-causes-silent-data-loss-bypassing-required-flag/87539 "2026-08-04T16:26:10Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Phantus](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/phantus/32/94917_2.png) [@Phantus](https://community.glideapps.com/u/Phantus)\ **Post date:** [August 4, 2026, 4:26pm UTC](https://community.glideapps.com/t/critical-bug-race-condition-between-native-forms-choice-components-and-row-owners-causes-silent-data-loss-bypassing-required-flag/87539/1 "2026-08-04T16:26:10Z")
**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:** 1. I am using a Native Form (Add or Edit) to write data to a standard Glide Table. 2. The destination table has the **Make Row Owner** feature enabled on specific columns (e.g., `admin_access`, `docente_access`). 3. 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). 4. 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: 1. The row is instantly created. 2. The Row Owner security rule triggers _before_ the entire form payload (specifically the Choice Component string) is fully committed to the database. 3. 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. 4. The Choice Component’s data insertion is rejected by the server. 5. 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. ---
**Author:** ![Jeff\_Hager](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/jeff_hager/32/43_2.png) [@Jeff\_Hager](https://community.glideapps.com/u/Jeff_Hager)\ **Post date:** [August 4, 2026, 5:17pm UTC](https://community.glideapps.com/t/critical-bug-race-condition-between-native-forms-choice-components-and-row-owners-causes-silent-data-loss-bypassing-required-flag/87539/2 "2026-08-04T17:17:56Z")
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? ---
**Author:** ![Phantus](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/phantus/32/94917_2.png) [@Phantus](https://community.glideapps.com/u/Phantus)\ **Post date:** [August 4, 2026, 6:15pm UTC](https://community.glideapps.com/t/critical-bug-race-condition-between-native-forms-choice-components-and-row-owners-causes-silent-data-loss-bypassing-required-flag/87539/3 "2026-08-04T18:15:08Z")
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 ---
**Author:** ![Phantus](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/phantus/32/94917_2.png) [@Phantus](https://community.glideapps.com/u/Phantus)\ **Post date:** [August 8, 2026, 5:49pm UTC](https://community.glideapps.com/t/critical-bug-race-condition-between-native-forms-choice-components-and-row-owners-causes-silent-data-loss-bypassing-required-flag/87539/5 "2026-08-08T17:49:58Z")
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: 1. Manual direct input in the Data Editor. 2. SSO tokens (SAML/OIDC) on Enterprise plans. 3. 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! ---
**Author:** ![Jeff\_Hager](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/jeff_hager/32/43_2.png) [@Jeff\_Hager](https://community.glideapps.com/u/Jeff_Hager)\ **Post date:** [August 8, 2026, 11:29pm UTC](https://community.glideapps.com/t/critical-bug-race-condition-between-native-forms-choice-components-and-row-owners-causes-silent-data-loss-bypassing-required-flag/87539/6 "2026-08-08T23:29:19Z")
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. ---
**Author:** ![NFNHello](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/nfnhello/32/3371_2.png) [@NFNHello](https://community.glideapps.com/u/NFNHello)\ **Post date:** [August 9, 2026, 1:02am UTC](https://community.glideapps.com/t/critical-bug-race-condition-between-native-forms-choice-components-and-row-owners-causes-silent-data-loss-bypassing-required-flag/87539/7 "2026-08-09T01:02:00Z")
> [@Jeff\_Hager](#): > > the role can only be set via a server side workflow 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. ---
**Author:** ![Phantus](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/phantus/32/94917_2.png) [@Phantus](https://community.glideapps.com/u/Phantus)\ **Post date:** [August 9, 2026, 3:13pm UTC](https://community.glideapps.com/t/critical-bug-race-condition-between-native-forms-choice-components-and-row-owners-causes-silent-data-loss-bypassing-required-flag/87539/8 "2026-08-09T15:13:40Z")
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. ---
**Author:** ![Phantus](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/phantus/32/94917_2.png) [@Phantus](https://community.glideapps.com/u/Phantus)\ **Post date:** [August 9, 2026, 3:15pm UTC](https://community.glideapps.com/t/critical-bug-race-condition-between-native-forms-choice-components-and-row-owners-causes-silent-data-loss-bypassing-required-flag/87539/9 "2026-08-09T15:15:12Z")
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. ---
**Author:** ![Darren\_Murphy](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/darren_murphy/32/47326_2.png) [@Darren\_Murphy](https://community.glideapps.com/u/Darren_Murphy)\ **Post date:** [August 10, 2026, 1:05am UTC](https://community.glideapps.com/t/critical-bug-race-condition-between-native-forms-choice-components-and-row-owners-causes-silent-data-loss-bypassing-required-flag/87539/10 "2026-08-10T01:05:38Z")
> [@Phantus](#): > > I’m asking why it is not clearly stated in the docs. It is mentioned a couple of times in the [FAQ section](https://www.glideapps.com/docs/essentials/security-and-user-data/roles) 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 🤷‍♂️ ---
**Author:** ![NFNHello](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/nfnhello/32/3371_2.png) [@NFNHello](https://community.glideapps.com/u/NFNHello)\ **Post date:** [August 10, 2026, 11:37am UTC](https://community.glideapps.com/t/critical-bug-race-condition-between-native-forms-choice-components-and-row-owners-causes-silent-data-loss-bypassing-required-flag/87539/11 "2026-08-10T11:37:53Z")
> [@Phantus](#): > > Everything is trivial in Glide if you don’t care about quotas. 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. > [@Darren\_Murphy](#): > > the docs suggest that using a Multiple Texts column is required 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. ---
**Author:** ![Darren\_Murphy](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/darren_murphy/32/47326_2.png) [@Darren\_Murphy](https://community.glideapps.com/u/Darren_Murphy)\ **Post date:** [August 11, 2026, 6:38am UTC](https://community.glideapps.com/t/critical-bug-race-condition-between-native-forms-choice-components-and-row-owners-causes-silent-data-loss-bypassing-required-flag/87539/12 "2026-08-11T06:38:33Z")
> [@NFNHello](#): > > 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. In a word, no. I’ve tested it.