Auto-fill parent ref in child from inline table?

Has anyone figured out the conditions that prompt the app to auto-fill the parent link when adding a row from an inline table?

1 Like

What you mean with …prompt the app… @Steve? Like a bubble for example or you mean some kinda auto-focus?

1 Like

When I click the Add link/button in an inline table:

In some cases, the form that opens will have an appropriate column pre-filled with a Ref back to the row I hit Add from; in other cases, no column is pre-filled. I can’t figure out why some auto-fill and some don’t.

As per my experience; it directly fills the Ref value if there’s a reverse-reference (isPartOf) but it does not if there’s a direct reference. When there’s a direct reference, I generally use a de-ref in the initial value of the ref column of the child table to recall the key column value of the parent.

1 Like

After some experimentation, I’ve found that if REF_ROWS() is the entirety of the column’s App formula expression, the Add button in the related inline view will auto-fill the column referenced in the REF_ROWS() expression in the new row. To retain this magic, the REF_ROWS() results cannot be modified in any way, such as by list addition or subtraction, or with SORT() or ORDERBY().


  • REF_ROWS(...)
  • (REF_ROWS(...))

Not magic:

  • REF_ROWS(...) + LIST(...)
  • REF_ROWS(...) - LIST(...)
  • SORT(REF_ROWS(...))
  • ORDERBY(REF_ROWS(...), ...)
  • FILTER(...)
  • SELECT(...)

IsPartOf, ON or OFF, appears to have no impact.

If you imagine an add-row operation is equivalent to an action of type App: link to another view within this app with a Target expression of LINKTOVIEW("form-view"), the magic REF_ROWS() expression appears to change the Target expression to LINKTOFORM("form-view", "parent-ref-column", [_THISROW]) (where parent-ref-column is the column named in the REF_ROWS() expression).


Sorry for being so dumb, but I couldn’t quite get why the ref column value is not auto-filled in the case of a direct reference but auto-filled in case of a reverse-reference on the contrary. Appreciate provided you can clarify the solution a bit more @Steve. Thnx.

I don’t know why, unfortunately. It’s just my observation. I think AppSheet recognizes a REF_ROWS() expression and treats in in a special way.

This is great info, @Steve! Thanks for testing and providing your results.

Could we get this added to the REF_ROWS() doc?




@Steve I’m not 100% sure, but I think I have found the other work around to keeping the magical effect. I have an EnumList of base Ref (mostly for back-end editing), and then a a VC of List base Ref with an AppFormula pointing to the EnumList (for front end inline display). Unless I’m forgetting about something else I did, I believe it keeps the automatic population.

This was working, despite the presence of Orderby(), for months in an app I have. It stopped working today and reverted back to this (I guess intended) behavior. :frowning:

I have no explanation for any such change in behavior.

1 Like

Very likely it was a bug… and it’s been squeaking by because no one would think that behavior is a bug.

But if the intended behavior is for the “Magic” to only work when you’ve got the system-standard Ref_Rows() - this is very limiting for data-schema design capabilities.

I’ll have to manage the standard-system inline view (so I can keep the magic), but I’ll have to create copies I may need (with OrderBy() and such) for calculation purposes - duplicating data. :frowning:

1 Like