Lookup fields should be editable. Instead of these fields being read only the field should be able to be updatable directly on the entity looking up the value. This would also differentiate it from a formula field that can already act as a lookup field.

I can understand the value of the idea, but I also worry that it could become dangerous in the wrong hands. Will less-techy users always realise that they are changing a property of a linked entity? Given that there can be lookups of lookups, it can easily reach a point where users are unwittingly manipulating data far removed from the entity they are looking at. I mean, I don’t hate the idea, I’m just a bit scared(!)

Could this be mitigated by access extensions? I.e. for a user to edit data in a lookup, they have to be on an access level where edit permissions is extended to the entity that is being changed.

Well, I was assuming that this was absolutely required anyway. I think users would not want the creation of a lookup field to allow access restrictions to become bypassed.

They do actually already work in this way. If you don’t have access to the related entity, but there’s a look up in the entity you do have access to, the look up is indeed visible. Except for rich text fields. [image] Lookups are visible to those with no access, but not rich text Bugs & Issues Not sure if this is by design or a bug. If it’s the desired behaviour, just lmk. If I share an entity with someone and it has a lookup to a linked entity the person has not access to, they will be able to see it. Except if this look up is a rich text field. It would be nice to also have rich text fields visible in lookups to those with no access to its entity. But its no big deal either. Just inconsistent and might be good to include in user guide.

[image] RonMakesSystems: They do actually already work in this way. If you don’t have access to the related entity, but there’s a look up in the entity you do have access to, the look up is indeed visible. Except for rich text fields. Just to be clear we understand each other, in the following situation: Tasks ← Project → Deliverables if an Admin sets up a lookup on the Task database to show the Deliverables from the linked Project, a Member who does not have access to the Deliverables database will see an empty lookup collection when they open a Task entity view. If they have do access to Deliverables, then they will see the looked-up Deliverables, no matter whether or not they have access to the Project database. I realise now that I may have misunderstood @danielbmarsh’s original request. I assumed that he was asking that entities could be added/removed from the lookup field collection. So in the above example, a user who has access to the Task and Deliverables databases could add/remove Deliverables via the Project’s Deliverables lookup (even if they didn’t necessarily have access to the Project itself). I think this is a risky capability to support, hence my original answer, but maybe I have missed the point.

Ah yeah. If it’s only about lookup to another relation (whether its to-many or to-one), it doesn’t show the entity unless they have explicit permission. But if I understand the original request, I think its not only about lookups to relations, but also lookups to basic fields. Where you have view permission on the lookups of basic fields, even if you do not have view access the entity itself. If lookups can be editable, and permissions work in the same way as now, the basic field lookups would be editable even if you don’t have edit access to the entity in which they live in. WHICH!! Would actually make for some kind of field permissions. You could make an entity “for edit” and and relate it to another entity with many fields, and add editable lookups to that entity and share that one. Now they can only edit those fields without access to the full entity. Ideally a lookup could have a “editable” switch. I think the misunderstanding was the main use case for this. I took it in the direction more of basic fields, but maybe the intention was more around relations. Not sure what was originally meant. [image] Chr1sG: So in the above example, a user who has access to the Task and Deliverables databases could add/remove Deliverables via the Project’s Deliverables lookup (even if they didn’t necessarily have access to the Project itself). I think this is a risky capability to support, hence my original answer, but maybe I have missed the point. But, I still don’t understand why this would be risky behaviour. If they have access to create and edit the entities, this is quite nice. Maybe the Project entity includes sensitive info. The weird part is that they are creating then an entity (allowed) but linking it to an entity which they do not have access to. Maybe questionable, but thats actually how it works right now kind of. See video: I couldn’t explain this by text, sorry. 2025-03-12 12-08-57.mp4 Google Drive file.

[image] RonMakesSystems: But if I understand the original request, I think its not only about lookups to relations, but also lookups to basic fields. Where you have view permission on the lookups of basic fields, even if you do not have view access the entity itself. Ah OK, I see. And that makes sense now for @Michael_Ichter’s idea to make it permission dependent. [image] RonMakesSystems: If lookups can be editable, and permissions work in the same way as now, the basic field lookups would be editable even if you don’t have edit access to the entity in which they live in. WHICH!! Would actually make for some kind of field permissions. And this (in bold) is why that probably won’t happen. It’s not that enabling it would allow for field-level permissions, but rather that support for field-level permissions would need to be in place to enable it(!) [image] RonMakesSystems: But, I still don’t understand why this would be risky behaviour. My concern wasn’t about access level risks, just worried that an everyday user could more easily modify data without being aware of the implications.

Also to add clarity: this is about editing specific field values. I was not thinking about editing relationship fields per se (but I could see use cases there) [image] RonMakesSystems: If lookups can be editable, and permissions work in the same way as now, the basic field lookups would be editable even if you don’t have edit access to the entity in which they live in. WHICH!! Would actually make for some kind of field permissions. [image] Chr1sG: And this (in bold) is why that probably won’t happen. It’s not that enabling it would allow for field-level permissions, but rather that support for field-level permissions would need to be in place to enable it(!) As much as I love the idea for field-based permissions, the idea was assuming the user has edit permissions to both DBs. If the user didn’t have edit permissions to the lookup DB then it can stay view only. [image] Chr1sG: My concern wasn’t about access level risks, just worried that an everyday user could more easily modify data without being aware of the implications. If this is a concern Formula fields could be used as these are view only and can serve just fine as a lookup field. Or you could toggle the lookup field on or off as editable.

[image] danielbmarsh: If the user didn’t have edit permissions to the lookup DB then it can stay view only. The problem is the way entity sharing works right now. Could change down the line, but right no it doesn’t care what permissions you have in the Lookup’d entity. If its in the entity you have permissions to, you get the permissions. So it would be a bit weird to give editor permission if you have editor access on the other entity, but give view permission if you have no access in the other entity (which it currently does). For consistency it would make sense to give edit access to the look up if you have edit access to the shared entity, even without access to the lookup’d entity. But this indeed could cause problems and idk how feasible it is from the backend. I think the lookup is another real, written field in the entity. So it makes sense that if someone has access to the entity, they can have access to the lookup. But they do not have editing (or any) access to the lookup’d entity. So any api call that tried to have them edit the other entity they dont have permissions to will be blocked. Unless! it’s saved as an editable field within the shared entity, and an automation runs in the background to sync it to the lookup’d entity. Kind of how even now, the lookups need to calculate in the background and take a second to load. You could actually not use look ups and set up your own automations. Where on change, it will update. But then you need to set that up on both sides of the relation. Then if there are more than 2 places, you need to add multiple update databases from the shared entity. But from each “lookupd” database, you only need to update the main shared one. So it will run 2 automations. 1. Update main. 2. Update the rest of them that main is linked to. Not ideal or simple as checking a box called “Editable”. But if your use case is urgent, this is a viable workaround I think. If its a single or multi select, you’ll be better off using a relation and not single or multi select. Lmk if this makes sense. I’m actually not sure myself haha.

1000% this! :star_struck: [image] Chr1sG: I can understand the value of the idea, but I also worry that it could become dangerous in the wrong hands. Will less-techy users always realise that they are changing a property of a linked entity? Make “editable” an option on each Lookup field.

[DONE] Editable Lookup Fields

Ideas & Features

mdubakov April 2, 2026, 2:04pm 14

released today

Topic		Replies	Views
Lookups are visible to those with no access, but not rich text Bugs & Issues	3	148	February 24, 2025
"Lookup" for buttons Ideas & Features	0	53	November 10, 2025
[DONE] "Joins" - include related entity's fields in Views Ideas & Features table-view	7	720	April 2, 2026
Lookup files field using relationships Ideas & Features	9	212	April 9, 2026
Field-level permissions Ideas & Features	15	539	October 14, 2026

[DONE] Editable Lookup Fields

Related topics