Detail Table Column Filter Based on Header Value (Shared Header Object / Text Single Lookup)

Nextworld Platform
1

I’m trying to determine whether this is possible using table settings only (not application configuration):

  • A detail table column filtered by a value on the header record

  • The header data object is also present in the detail

  • The field used for filtering is Text – Single Lookup

  • Filter applies within the same header–detail relationship

Is there a supported way to reference the header value directly in a detail table column filter via table configuration alone, or are header-aware filters at the table level not supported?

Looking specifically for any native table settings / capabilities / limitations, rather than application-based workarounds.

image
image348×713 19.2 KB

2

Just to confirm some added context:

  • Is it correct that you’re interested in filtering the detail records, not assigning them values from the header?

If that is the case, Common Fields will not work. As far as I know, every tool for filtering is established in the Application layer, not the Table. Common Fields will assign detail records the value from the header, but that is the only Table-level “filter”. Common Context is the solution that comes to mind for filtering purposes but works at the application level - this is true whether using a header-detail app or an inline application.

Ultimately, I believe the reason for this is that filtering is inherently a UI-based action and not one that manipulates data - adding a filter as a user does not have a direct impact on a database record.

The closest you can come outside of the UI is with a logic block that uses header fields as filter criteria for a Fetch Records action, but that won’t have any UI impact if you need records to be filtered visually, it will just change processing.

3

Thanks, Ross — that aligns with what I was trying to validate.

Yes, the intent is strictly to filter which detail records are visible, not to assign or propagate values from the header. My focus was specifically on whether any table-level configuration exists that supports header-aware filtering, independent of application or UI constructs.

Your explanation around filtering being inherently UI-driven and therefore scoped to the application layer makes sense, and it’s helpful to confirm that Common Fields are assignment-only and not a true filtering mechanism in this context.

This answers my question and confirms there isn’t a native table-level approach for this use case today. Appreciate the clarity.