Auto populate based on USEREMAIL()

Hi,

I have tables with USEREMAIL() in [User Id] Columns. This is used to retrict and direct the user to the correct view. Is it possible for appsheet to autocreate a new row in a table based on the fact that a new user has been created. This would mean they wouldn’t have to create one themselves.

Below is the table that a user can input various criteria. There are actions buttons to link to a view based on a slice based on the conditions they have set. To stop muliple users interfereing with each others inputs they can only view and manipulate the row with their USEREMAIL() in.

I tried adding an action button to create a new row with their useremail but the bitton won’t appear unless there is a row to show - which there isn’t becasue their useremail isn’t there yet.

Thanks

Phil

Unique ID County Price List Outlet Rating Outlet Type User Id
1 Cheshire , Cumbria , Lancashire , Merseyside , North Yorkshire , West Yorkshire Band 1 , Band 2 , Band 3 , Band 4 , Custom Check Festival , 0 , Social Club , Individual , Free , Pub , Micropub , Club , Off Licence , Bar , Hotel Bar , Sports Club , Event , Other , Caterer , Shop , Restaurant hilary@listersbrewery.com
2 Cheshire , Cumbria , Lancashire , Merseyside , North Yorkshire , West Yorkshire Band 1 , Band 2 , Band 3 , Band 4 , Custom Prospect with contact made Festival , 0 , Social Club , Individual , Free , Pub , Micropub , Club , Off Licence , Bar , Hotel Bar , Sports Club , Event , Other , Caterer , Shop , Restaurant phil@listersbrewery.com

Nope. Your best bet would be for the app administrator who adds the user to also add the user to the table at the same time.

Wait… what? I thought we could now @Steve?

What about this action? Isn’t this the background row creation action? (“Background” meaning it happens without a form needing to be opened and saved.)

1 Like

Well, I’m going to contradict Steve slightly by asking, in what way is this new user being “created” with this new email address?

In general, Steve would be right. If you add a new user’s email to the whitelist so they can log in, that doesn’t trigger anything. It’s not a table to work with. Now, if you have a table where you also store this user’s email, then yes, you could use that action to do it. Either way, the email address would need to exist somewhere within the App before using the action.

1 Like

This was the basis of my statement.

2 Likes

I think I was reading this backwards… @Phil_Waite I was thinking you were saying when adding a new user into the user table, to trigger the creation of a row in another table.

1 Like

Thanks guys.

I could get the app to open with a view of a tabe that contains only USEREMAIL()s and put and action button to add the user to the list if it’s not there already.

2 Likes

Jumping onto this excellent thread, hope that’s OK

I’ve built a field service timesheet App. Engineers can update their Daily Work times and at the end of the week submit a weekly timesheet.

Additional Management Apps have different views of the data.

I want to associate the Timesheet App with individual engineers so that only they can create their own timesheet.

I have fields in the Employee Table called “Engineer Name” and “Engineer Email Address”

I’ve created a Ref from the Timesheet Data Table to The Engineer Table for “Engineer Name”

When the App is loaded I’d like the two fields above to be populated with the Engineers name or email address, I don’t mind which, I just want to associate the timesheet with the person completing the form.

I’d like the association between the Engineer and the Fields to be hidden from the mobile App

Hope this makes sense and someone can point me in the right direction

Thanks

Stephen

1 Like

Hey Stephen, no worries - all are welcome! :slight_smile:

There’s a couple of ways to accomplish what you want:

I usually advocate the creation of a Current_User slice - this gives you an easy way to call any of the data stored in the User table for whoever is currently using the app.

Then to prepopulate a field, you can just do something like the following in the initial value for the fields: any(Current_User[Engineer_Email_Address]) to automatically pull in the email from the user table; any(Current_User[Engineer_Name]) for the name; etc.


or

you could use a LOOKUP() to simply find the values you wish from the User table based on the USEREMAIL() of whoever is using the app; you would put these in the initial value space.

LOOKUP(USEREMAIL(), Users, Engineer Email Address, Field_you_wish_to_pull)

1 Like

You could also make use of Private Tables.

1 Like

Another solution might be to have a multiple action where the event on a row selection adds the USEREMAIL() to a table. The idea would be that by the time the user uses the funtion that requires a useremail they will have navigated around the app and triggered the event.

If you’re going that route, I’d advocate the creation of some sort of “Welcome” screen… a splash screen of sorts that users see if they don’t have a user record in the user table; to the user it’s a welcome page, for the system it’s creating their user record.

The welcome screen is a form, that they save. Make this a conditional opening view, otherwise send them to whatever. This way, when new users log in, they see this welcome screen and move on to use the app.

This creates their user record - it just looks like a welcome screen to the user. You could add in other data collection elements here if you wanted, like upload an avatar or something, but the point is it looks like a welcome screen and the “Save” button looks like a “Let’s go” type of thing.

Tricks. :nerd_face: User never knows what was just created and they use the app like normal.


so what happens when someone cancels out of the welcome screen instead of hitting the camouflaged save button, I hear you asking???

Luckily, every element of an app (views, actions, hell… the data, everything) has the ability to be conditionally shown to users based on criteria - such as having a record in the user table. :wink: :