Current_User (Slice) - How to conform your app around WHO is using the app

There’s no sure-fire way to prevent the user from canceling out of a form.

In order to force a User table entry for a new user, the user must do something with the app that will trigger an action. The action can then add the current user to the Users table. The problem is that the main menu entries and the navigation buttons along the bottom of the screen can’t trigger actions, so you have to present a view to the user that forces the user to either save a form (which can trigger an action) or press an action button. Action buttons can’t be placed on forms; all other view types require at least one pre-existing row in a table. Whether you use a form or a view atop some pre-existing row, you still have to prevent the user from navigating away from the view, which means removing all main menu and navigation bar entries. There’s no simple way to do any of that.


Thanks for that explanation. It helps a lot. Then would how does this work? When is the initial value of the User Setting resolved? We need it to be resolved after the User exists in the table.

And can we request a setting that tells if you can reject the open form? Simple enough to implement. This would be useful in many other places.

User settings is handled like any other table: the user settings row doesn’t exist until the user goes into it and saves it.

If you’re going to have a Users table, best to use it rather than use user settings at all.

But we need to use UserSettings(Current User) everywhere in the app instead of USEREMAIL()/USERROLE() value to do this Tip/Trick!

I don’t think that’s the same feature. That simply wants ‘Cancelled’ Action. I want a ‘Show If’ for ‘Cancel’ button when you’re in form view so you cannot go back. You have to fill it and finish saving.

Ah. That’s a question for @MultiTech_Visions, then.

Very good strategy. Unfortunately I am very new to Appsheet and I would like to ask you if you have an example “Mini-App” that could show this implementation for reference. It’s possible?

So I am trying this method because it seems better than the way I had it set up. The difficulty I’m having is I want any user logged in to be able to view and edit their rows based off of the associated company.

Example: David & John both work for ABC, LLC. They should both be able to view and edit records for ABC, LLC.

I have followed all the steps above and can’t seem to get the result I’m looking for. Any guidance is appreciated.

1 Like

It seems to me that if you used a security filter to only show that companies data in the app, then you wouldn’t have to restrict add/edit/delete permissions.

  • Because then, the data shown in the app is only for that specific company.

But if you wanted to control who can do what, you’ll either need to:

  • use a “Role” based system (ie. “Admin” roles can edit things, but “Users” can’t); or
  • control things on the individual actions.

If using a role-based system

You can use an Update-Permissions formula on the Companies table (inside the “Are updates allowed?” space) like the following:

switch(index(Current_User[User_Role], 1),
	"Admin", "ALL_CHANGES",

If you wanted to control things through Actions

Each individual operation that can be executed on a table (add/edit/delete) is controlled through an action for that table; and you can base whether any action should be seen or not based on data from individual records.

  • So for the “Edit” action on the Companies table, you could do something like the following:
    INDEX(Current_User[User_Company_Link], 1) = [CompanyID]

  • You might also throw something in there about only allowing “Admin” types as well:

  INDEX(Current_User[User_Role], 1) = "Admin", 
  INDEX(Current_User[User_Company_Link], 1) = [CompanyID]

NOTE: I originally posted an incorrect statement, which caused confusion and the comments after this one are based on that erroneous info. The previous details can be found here.

Then inside the “Are updates allowed?” space for the Companies table…

…use a formula such as this:

For a single ref column

IF(INDEX(Current_User[User_Company_Link], 1) = [CompanyID], 

For an EnumList of refs

IF(IN([CompanyID], SPLIT(CONCATENATE(Current_User[User_Companies]), " , ")),

I might also include something about only allowing Admins, if you use a Role-base permissions system:

  INDEX(Current_User[User_Role], 1) = "Admin", 
  INDEX(Current_User[User_Company_Link], 1) = [CompanyID]

Thanks! I will try implementing this and see if I can make it work.

1 Like

You might also find some helpful tips from this post as well:


Thanks again. I can’t get this to work to save my life. The current error I’m receiving is "
Table ‘Companies’ has an invalid update mode expression ‘=IF(INDEX(Current_User[User_Company_Link], 1) = [CompanyID], “ALL_CHANGES”, “READ_ONLY”)’. Unable to find column ‘USER_COMPANY_LINK’

The User’s table is a single ref column to the companies table. I have not tried implementing any of these formulas on the work orders table for the companies, since I cannot get it to work on the companies table yet.

I have also tried changing the companies column to EnumList of refs and using your recommended formula.

I appreciate any help. I have been at this specific problem all week and I feel as though something this simple should not take this long.

1 Like

Hey @rmsmeltz

The problem you’re having is that you’ve just copied the sample formula I provided; you’ll need to change the column names so they match whatever you’ve got in your system.

So in the formula, [User_Company_Link] should be replaced with the column name that IS the ref column to the Companies table.


I tried it that way at first, then I changed the names of my columns and types to match what you showed me in the example so it was easier. It still gave me that error message.

@MultiTech_Visions I’m watching the extended version of your video on Patreon. I don’t think I have my users and companies tables set up properly. Can you provide any more in-depth guidance on how to make sure they’re set up correctly?

Hmmm… at this point it might be best to move this into it’s own discussion, instead of at the bottom of this Tip & Trick post.

1 Like

You can’t specify the Update Mode per record like this. Here you are setting it for the entire Table. If you need to specify it per record beyond this, then do so by filtering down in a Slice, and setting the Update Mode of the Slice.

The expression assistant is not infallible. Sometime the reported error is not actually the real problem. This may be one of the cases. To double check this exact error, just try to set some temp VC expression in some Table to


You know @Marc_Dillon you’re :100: about not being able to do things on a per-record bases here; I can’t believe I missed that. lol I have no idea what I was thinking. :crazy_face:

Honestly, I’ve actually taken to controlling edits and things on the Action side of things, I rarely use the actual table-updates permissions anymore.

  • You can control EDITS through the edit action
  • You can control DELETES through the delete action
  • You can control ADDS through the add actions

And with actions, you can control them on a per-record bases.

So I just put my “access” permissions formulas inside the individual actions for each table nowadays.

Now to figure out a way to clean up this post! haha



How do you actualy use it with views/slices? Do you add this condition to any slice with AND()?

Matt, but please remove the “backdoor” because that is inviting a security hack. Nobody should allow user impersonation that way in their apps. USEREMAIL() is something the platform controls and not hackable. Having a lookup table is not just a backdoor but really a frontdoor also :]

1 Like

Speeking of hackers, could you do a webinar about how secure appsheet is in terms of cyber security? And ways for us as creators to know what to do to make it safer