I have multiple views which I use, but not all information needs to be displayed when I add a record through a linked record. Right now, it seems whatever view is at the top of the list in a table is the one that shows up when a linked record is used.
It doesn’t look like this is possible - at least not in the desktop/browser app - it always shows the ordering of fields defined in the first view in the list of views from the source table.
Interestingly, in the #ios app, you can manipulate a table with linked records to show a different view when expanding a linked record - it will show the order of fields from the view which you last selected in the source table. In the example below, I expand a “Sample” record which is sourced to the “Cylinders” table. The first time I do it, “Job” is the first field shown after the “Name”. Then I change the view in the “Cylinders” table (the source table for the linked records), and go back and re-expand a “Sample” - this time it shows “Load (lbs)” as the first field:
I presume this happens because the #ios app handles the expanding of a linked record in a completely different way than the desktop/browser app does. Where the desktop/browser app expands the record as an overlay on top of the currently open table, showing a line linking the record to its source table – the #ios app opens the record in the same way as opening a record directly from a table - the record arrests the entire view in both cases. Presumably this means that expanding a linked record in the #ios app is doing the same thing as expanding a table record – simply calling the URL, or URI, or something like that, of the record and displaying it.
I agree, it would be nice to have some control over this as a user (#feature-requests) . Perhaps the best place for adding this as an option would be in the view options:
An option to “Set as linked record field order” for the view, and perhaps even to specify which view in linked tables will use this view as the field ordering view when expanding the linked records, would be helpful.
However, I suspect this could get complicated to integrate into the #ios and #android apps; plus, Airtable has much bigger fish to fry in the #feature-requests department - so I’m not holding my breath.