Unexpected behavior with Row Owners and Role assignment on first sign-in

Ask for Help
1

Hi everyone,

I’m running into a puzzling issue with Row Owners and visibility right after a new user signs in. Here’s my setup and what’s happening:

  • My app has a sign-on screen where a new user enters their Name.

  • A Go button appears once the fields are complete.

  • Pressing Go runs an action that:

    1. Checks the user’s Email against an If-Then-Else column to detect their company domain (e.g., randomagency.com, partnergroup.com, etc.).

    2. Writes the resulting company name (e.g., “AgencyA” or “PartnerGroup”) into the Role column of the Users table.

  • The Role column is a basic text column (not computed) and it visibly updates as expected — I can see the value appear in the Data Editor.

Then:

  • The sign-on screen is set to disappear when the Role column is filled, revealing the Home screen.

  • The Home screen contains a collection pulling from another table where the Row Owners column is also “Role” (role-based ownership).

  • The role text in both tables is identical (e.g., “AgencyA”).

Here’s the problem:

After sign-in, the collection stays empty, even though the Role value clearly matches the Row Owner value.

If I go to the Data Editor, manually retype the exact same text (for example, “AgencyA”) into the Users table Role column and return to Layout, the collection suddenly becomes visible within a second or two — so the matching logic does work, but not immediately after the automatic action runs.

It feels like Glide isn’t recognizing the new Role value as “real” until I manually edit it — as if the automatic write doesn’t trigger a security or ownership refresh.

Has anyone experienced this timing or recognition issue before?

Is there perhaps a workaround — for example, adding a short Wait or Shuffle step in the “Go” action — to force Glide to re-evaluate or acknowledge the change in data immediately?

Thanks in advance for any insights or workarounds!

— Simon

2

How are you adding the value to the role column? It should be with a server side workflow or API.

3

Thanks for the reply!

In my setup, the user’s email address is checked through an If-Then-Else column in the Users table, which determines the user’s company or domain group (e.g., by looking for a domain fragment like @randomagency.com).

When the user presses the Go button on the sign-on screen, a custom action runs that sets the Role column in the Users table to the result of that If-Then-Else column. This part seems to work correctly — I can see the Role value being written in real time to the user’s row during sign-on.

However, even though the value appears instantly in the data, the collections on the Home screen (which rely on that Role value for visibility and Row Owner logic) stay hidden until I manually re-enter the same text in the Data Editor. It’s as if the automatic write doesn’t trigger Glide to refresh ownership or visibility immediately after the sign-on action.

4

Glide will clear the value as soon as it syncs with the back end. Roles cannot be set via user interaction workflows. As @NFNHello said, you must use either a server side workflow, or the Glide API.

5

Thanks for clarifying that — that really helps.

Can I just check something?

Would it be possible for the Go button to trigger a Glide API call directly?

I’ve seen another community tip where someone used Make.com to call the Glide API successfully, and I understand that API actions can essentially access the app as if they were running with admin-level permissions.

However, I’m wondering how that applies when the API is triggered by the end user themselves — for example, from the Go button on the sign-on screen.

Would the call still execute with full app-level permissions (like the owner/admin), or would it be restricted in some way because it’s initiated from a user action rather than from the backend

6

Yup, you can use an app interaction workflow with a Call API or Trigger Webhook action to set the user role.

7

I’d recommend a manual trigger, saves messing with the API. It runs with full privileges, regardless of the user that triggered it.

8

Here’s an example

9

I understand the manual approach however I want to set up in advance a short list of private networks, and use the logic of the email to assign the new user automatically into the correct network. There may be times when I am not alerted to a new user for several hours, and this may cause frustration with new users who are expecting instant access.

10

Yes, that works well for a manual approach. However, I need it to be triggered. At sign in.

11

Perhaps you don’t understand what a manual trigger is?
It will be fully automated.

12

OK, you mean trigger manually by a user event. Yes that will work perfectly. Apologies I thought you meant manually going into the data tables and writing directly into the glide table.

13

Yeah. Apologies for my terse replies, but I’m outside. If you watch my video you should get the idea. I think in the video I might have used a webhook trigger, but a manual trigger works just as well.

14

No your replies and especially the video are super helpful. You first showed a webhook trigger using make then made another using a Glide webhook… very cool.

15

Webhook method now implemented and working like a dream. I also like the idea of adding other actions such as email notifications, etc…

Thanks.

17

I’m looking into users editing their own role.

What I think I understand:

Glide blocks role changes triggered directly from inside the app by design (for security purposes, supposedly). But a webhook-triggered workflow runs server-side, outside the user’s session context (i.e. not on the user’s device). Glide treats the workflow as a trusted external instruction, not a user action. So the restriction doesn’t apply. Even though the workflow was triggered by a webhook which was itself triggered by the user.

So really, we’re being secure by preventing the user to edit their role via an app interaction workflow. And yet we’re also being secure by allowing the user to edit their role via a chain of workflows, namely an app interaction followed by webhook-triggered workflow.

  1. How does this make any sense?
  2. If we’re going to allow users to edit their role anyway (it’s technically possible), why make it so complicated?
18

Anybody can manipulate or override the code and network traffic running on the front end of their own device. What they can’t control is the code running on the backend server.

Let’s say you never explicitly built a feature to change a user’s role. You obviously don’t want someone manipulating API calls to illegitimately change that role and gain access to data they shouldn’t have access to. That’s a simple recipe for disaster.

When you intentionally build a role-changing feature on the backend, you as the developer have far more control over the logic and who is allowed to run it. It’s no longer about somebody tampering with API calls. It’s about deliberately creating a controlled process and enforcing strict conditions around when and how it can execute.

Sure, the process is more complicated, but that complexity is intentional to protect user data, not to make simple things difficult. Just because you expose certain controls or UI components in the app doesn’t mean users can only interact with your APIs in the ways you intended.

19

Your explanation makes a lot of sense.

It’s simply a little frustrating at times (to me) that I feel one needs a PhD in Glide to achieve certain results that I feel should be somewhat straightforward (or more straightforward than they are).

I’m setting up a role-change feature via webhook. It’s probably not difficult, but it’s not easy either. I’d guestimate that a minority of Glide users find this feature easy to set up, which means that an overwhelming majority find this difficult and will ultimately fail to set this up correctly. I’m not convinced it needs to be this difficult.

Let’s take this very example, “intentionally building a role-changing feature on the backend”. If we take a no-coder who doesn’t already have experience developing with code (by trade or as a serious occupation), and this happens to be my profile, there is no way they are setting this up correctly without reading documentation and fiddling around. To me at this point, the no-code process has broken.

20

Yes I agree that role changing is something that Glide should probably make as a plug in feature (and allow a default role to be set automatically for new users, for crying out loud), but it needs to be especially clear that everything is set up in such a way that only those with the proper authority are the ones capable of accessing that feature while also allowing for edge cases where role changing might need to be a little more flexible.

At least Glide is being proactive by doing a lot of security for us and restricting what can and cannot be done client side. But they could be a whole lot better at providing warnings and hints, and providing best practice instructions so the rest of us don’t have to rehash these questions and solutions hundreds of times.

There are a lot of things that need improvement in Glide. But at the end of the day I still believe it’s crucial for the developer to understand the architecture of the stack they are using and security best practices in general. It’s knowledge that just takes time and experience to understand and master. Just because anyone can fly an airplane in a video game, doesn’t mean they should be doing it in real life, and likewise just because anyone can now build a no-code or vibe coded app these days, doesn’t mean they are following best security practices. Some of that stuff is very complex and always will be complex because it’s a constantly changing landscape and there is always someone looking for an exploit.