Add rows to another table WITH parameterized input

This pattern comes up more and more, so I thought I’d build a simple example.

We already know that you can copy rows using the “add rows to another table” action. But sometimes we want our end user audience to provide some input first. The attached app shows a simple way to do this.

At its most basic, the design has an “extra” table whose only real purpose is to allow data entry of a single row of info. This info could then be used when calling the “Copy” action.

So… in our fictitious example, an event planner wants to be able to add line items to an event. They have a library of line items, and they have a list of clients who have events.

In the menu, we have provided “step 1” and “step 2”. (This could all be done on a dashboard as well).

Step one is that the event planner picks which event they want to work on, and step two allows them to add line items to that event:


Here’s the sample app:

It only has one single action in it. Enjoy and best regards.


Yes, it is one of the required features to let the user to decide the value to new row when the appsheet action is fired. Not sure how the other member like to have, but on my case, the required process is like this.

  1. App user hit the action button explicitly.
  2. Window (appsheet view) pop up, asking the user to select the choice out of the options or manually enter the arbtray value by typing in and hit save or proceed, or even cancel action.
  3. The appsheet action will take this value and push to the designed field and add the row to this or other table.

I have a workaround with this, but not creating any sample with me. Will do when I have spare time to share my idea.

1 Like

Thank you @TyAlevizos
What would you do if many users are working in the App?
Would you add a USEREMAIL() column into the extra table “currenteventselected” and a Security Filter to this table with the expression [UserEmail_Column] = USEREMAIL() ?


This would be my guess. I use the same approach to give each user their own row of a Search table and use a security filter with USEREMAIL().

You can also add a column for [DeviceID] using CONTEXT("Device") instead of USEREMAIL().
Then, each user can log in on multiple devices and have separate ‘sessions’ for their search, or in this case, for copying rows.

I used USEREMAIL() at first, but one user liked to have the app open on their phone and PC at the same time and didn’t like the search from one device over-writting the other.


This is a very cool idea @GreenFlux


Thanks @Fabian! :slight_smile: It’s the only good use I’ve found for CONTEXT("Device") since it’s not actually consistent per device. Each browser reports a different ID, and another different one when in private mode, plus the one from the app (on mobile)– which I believe changes with re-install.

So don’t use it for anything critical. Or at least make sure your users know to always use the same browser and not use private mode. I think it’s fine for a helper-table but I would be very careful using in real data tables.

1 Like

great comments, all. Thanks! Especially around record locking. I coincidentally created a “simple record locking” app example, which I guess is relevant here as well? In the following app, we have some lock and unlock AppSheet Actions which update records to then prevent the EDIT button from appearing unless a) you own the record or b) no one owns the record:

Lots of different directions this kind of design can go in, of course. Note: conditions on system buttons like “EDIT” could in theory get expensive at larger scales. At least this condition doesn’t run a select() statement :slight_smile: it could be worse…

Here’s that simple example:


Basically, the same tricks behind, which is used in this app. On this sample case, I created 2 table, table 1 and table 2.

When the user fires the action to copy, then prompted immediately to the form to select the value for field which is NOT on the table 1, but there in Table 2. In this case, I say “sub category” which is selected by the user before the copy is done. Once the user select the value, then copy is done. The selected value for this field are copied to table 2, and the rest of the field value on the table 2 is just copied from table 1 row.

It worked as I supposed.

On every single occassion, the user is in attempt to copy a row, they are asked for the “value” to be assined to new row on table 2.

I believe this is simple and user friendly UXs.