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.
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.
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.
Ah OK, I see.
And that makes sense now for @Michael_Ichterās idea to make it permission dependent.
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(!)
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)
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.
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.
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! 
Make āeditableā an option on each Lookup field.
Just found its related to this:
I thought Iād giving it a shot with automations. You can copy the space:
The issue is when the ālookupā relation is empty, its still an editable field that is not linked to anything. Solved it by automatically creating the lookup relation, but this might cause duplicates depending on where the data is, and where it is being inputted. Depends on workflow this part can be adjusted.
Its less neat than an āeditableā switch, but if its a problem you need solving right now, hereās a way you can copy.
Note: this bypasses permissions. They will be editing entities they do not have access to edit, through the āeditable look upā