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
0 11 1,828
11 REPLIES 11

Steve
Platinum 4
Platinum 4

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.)

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.

This was the basis of my statement.

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.

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.

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

Hey Stephen, no worries - all are welcome!

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)

You could also make use of Private Tables.

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. 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. :

Top Labels in this Space