I just noticed today that lookup fields that return *-to-many relations are automatically rendered as list views. So unlike other relation fields, you are not able to create a different view type (grid, map, calendar, …).
Even the list view seems to be a stripped-down version which does not offer the same customization as normal list views (i.e. no sorting, no colour coding …) . You are able to select the fields to be displayed. However, the order the fields are displayed cannot be changes and they would appear in alphabetical order.
Are there any plans to transitioning lookup relations to have the same view options as normal relations with all/most of the same options?
Is there a workaround for this currently?
Nothing in the short term is planned, but probably eventually…
In some cases, an auto-linking relation can achieve the same as a lookup, and will have more capabilities
This is what I had done in past instances too because I had found lookups to be quite limiting. However, I haven’t been able to figure out how to use this trick with many-to-many relations?
My specific situation is as follows:
I have a list of Projects which may have 1 or more Accounts associated with them. Each Account has a Funding Source associated with it. What I want to be able to do:
- Be able to list all Projects associated to each Funding Source (through the Account)
- Be able to list all Funding Sources associated with each Project (through the Accounts)
Lookups allow me to do this. I haven’t been able to figure out how to accomplish this with auto-linking relations since the key fields are collections rather than discreet value/entities.
Any brilliant idea you may have is greatly appreciated.
Unfortunately not. Yours is an example of where auto-linking can’t help
One possibility would be to replace the Project lookup in FS with a relation to Project, then use automations to maintain the collection.
The drawbacks: 1) more complexity, 2) as a relation it could be manually disrupted (e.g. something unlinked by mistake).
One Rule fires whenever an Account is linked/unlinked to a FS, and the Rule then links/unlinks the FS with all the Account’s Projects.
Second Rule in Account or Project monitors when a Project is linked/unlinked with Account, and makes the appropriate adjustments…
Not entirely sure this could all be done correctly with no-code, but it could certainly be done with scripts.
This is great. I thought an automation might be the only option. I was hoping to avoid it as it does become harder to maintain them over time. But thanks for detailed description.
i will keep this request open as I think the main point about lookups still stands