Nested Forms? Fill out two tables in one form

I’m working on an enhancement for my chicken inventory app to track egg incubation through maturity. Here’s what I’m trying to achieve:

  • Batch Table: Stores BatchID, SetDate, and other batch-level details.
  • Eggs Table: Stores details of individual egg groups (usually 4–6 per batch), including EggID, fertility rate, and hatch rate.

Goal: Create a single form that lets users:

  1. Create a new batch (saving to the Batch table).
  2. Add multiple egg groups (saving each to the Eggs table) with their fertility/hatch rates, linked to the same BatchID.

Question: How can I design this in Glide? Ideally, users would fill out batch info first, then add egg group details in the same form—without needing multiple submissions.

I’ve considered:

  • Using a form with a repeating section for egg groups.
  • Using actions to update both tables after submission.
  • Relationships between tables (e.g., Eggs linked to Batch via BatchID).

Has anyone built something similar? Any tips on structuring the tables or configuring the form would be amazing!

Thanks

Rommel

What’s the difference between a “batch” and an “egg group”? Usually there are 4-6 egg groups per batch?

Generally speaking, if you are creating a new row in a Batch table, and then a new row in an Eggs table related to the batch just previously created, I would create two separate native forms.

Totally agree with @nathanaelb about two different forms: for data reasons, for UX reasons and for simplicity reasons :stuck_out_tongue:

Here’s a quick example of something that comes close to your request. The idea is to simulate a 2 steps form in order to provide to users a flowless approach.
2 steps form: Batch → Egg Group


The Data part is based on 2 tables, Batch and Eggs:



In the Layout, a Table component let you add data to Batch table

The nice option here is to change to “On Submit” action to “Show detail screen > This item”. It will trigger the second step to let user add egg groups:

And at the end, we have a… Data Grid (with Related Eggs column as Source) with an “Add en Egg Group” action:

Because it was easy and fun to do it with Glide, you can also add a “Delete row > This Item” action column, to let user Delete a specific row if he/she has added to many (for instance):


It’s just an idea, and to summarize your considerations:

UX reason: from a User perspective, please do not add “empty” sections if it’s not necessary. The Data Grid is cool because it’s the user who decides the number of rows to add (with a Delete option)

Simplicity reason: even if it’s possible to do that in Glide, you would use a single workflow to mix two differents topics. It’s easier to have one action to make something (like adding a new Batch) and another one to make something else (like adding an Egg Group). This way, you’ll also be able to reuse the “Add an Egg Group” workflow if you have to edit a Batch later on (for example).

Data reason: you’re right my dear Rommel, very clever to create a relation between these two tables. Because you open the Detail Screen of a record, you can easily pass the Row ID value to the “sub” form. That’s what we do here :wink:


Hope this gives you some insights :slight_smile:

4 Likes

Hello to you too, Nicolas :slight_smile:

I tend to avoid this. I rarely use the On Submit action, and when I do, I avoid an action that will apply to a row that was just created. I think I learnt this from Jeff or Darren. It makes sense, since in this particular instance, applying an action upon submission to a row that was just created a fraction of a second prior might be looking for trouble. What if the on-submit action triggers just before the row is added to the database?

:backhand_index_pointing_up:
I agree with this 100%.

1 Like

In my experience, this works fine. It’s only when you do “Set columns” that the problems start to appear.

I usually don’t have the allowance to be able to have 2-step forms like what Nicolas suggested. Clients usually want to be able to add children items in the same form screen.

My workaround is using a custom form. I set a unique ID on entry to the form screen, then allow them to add/edit/delete the children items using that unique ID and a relation.

In those cases, there’s a chance they abandon the form mid-way and you have children items that are never associated with a “completed” parent item. I set up a workflow to delete them if the relation to a parent isn’t there after 2-3 days.

2 Likes

That’s the approach that I use.

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.