The columns in the sub-table have a "required" attribute, which is causing an error and preventing it from saving

AppSheet AppSheet Q&A
1

I have a parent table “father” and its child table “father_item”. The child table has “period”, “trans_date”, and “description” set as required columns. The “period” column also has a “Valid If” condition.

When entering data, all of these columns are fully filled out via the child form inside the parent form. Everything seems fine until I try to save the parent form, which triggers a “period is required” error.

If I make “period” not required, it then says “trans_date is required” and won’t let me save. If I make all three columns not required, the parent form saves successfully.

This issue just started happening today. Can anyone help explain what’s going on? Has AppSheet changed the logic for required columns or parent-child relationships recently?

2

Please post screenshots of:

  • father table columns list
  • father_item table columns list
  • period column configuration
  • period column Required and Valid if expressions, if any
  • configuration of the view you’re having problems in
3

Thanks for checking in, brother! I actually managed to track down the root cause of this headache, and it boils down to a lovely combination of two things:

  1. The “Automatically re-open the form after saving” (Auto re-open) feature enabled on my input form (father_item_Form).
  2. AppSheet’s current UX behavior.

Here is how the trap gets sprung:
When you finish entering a record on the father_item form and hit Save, the app immediately opens a new blank form for the next entry. Once you are done inputting your data, you naturally want to close this blank form.

In the past, hitting either Cancel or the Back Arrow in the top-left corner of the form worked perfectly to dismiss it. Now? You must tap Cancel to discard the blank form.

Out of sheer muscle memory, I kept hitting the Back Arrow. Every time I did, AppSheet decided to silently commit a blank draft record to blackbox. Because of this, saving the parent form threw endless validation errors—until I got so frustrated that I stripped the Required constraint from every single column. Once those constraints were gone, the form saved, but at a cost: a completely blank, useless trash row was written directly into my database.

My user behavior might have been a bit stupid robotic, but whoever designed that backward arrow on the form truly understood user flow—unlike the genius who changed the codebase to automatically commit a blank row on a back-action. That is truly galaxy-brain engineering right there.

I seriously hope that wasn’t an AI-generated recommendation. Thank God!