# \[DONE\] Editable Lookup Fields **URL:** \ **Category:** Ideas & Features\ **Created:** [March 11, 2025, 4:01pm UTC](https://community.fibery.io/t/done-editable-lookup-fields/8424 "2025-03-11T16:01:42Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![danielbmarsh](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/danielbmarsh/32/13104_2.png) [@danielbmarsh](https://community.fibery.io/u/danielbmarsh)\ **Post date:** [March 11, 2025, 4:01pm UTC](https://community.fibery.io/t/done-editable-lookup-fields/8424/1 "2025-03-11T16:01:42Z")
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. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [March 11, 2025, 7:30pm UTC](https://community.fibery.io/t/done-editable-lookup-fields/8424/2 "2025-03-11T19:30:44Z")
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(!) ---
**Author:** ![Michael\_Ichter](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/michael_ichter/32/9931_2.png) [@Michael\_Ichter](https://community.fibery.io/u/Michael_Ichter)\ **Post date:** [March 12, 2025, 8:13am UTC](https://community.fibery.io/t/done-editable-lookup-fields/8424/3 "2025-03-12T08:13:58Z")
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. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [March 12, 2025, 9:13am UTC](https://community.fibery.io/t/done-editable-lookup-fields/8424/4 "2025-03-12T09:13:06Z")
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. ---
**Author:** ![RonMakesSystems](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/ronmakessystems/32/14122_2.png) [@RonMakesSystems](https://community.fibery.io/u/RonMakesSystems)\ **Post date:** [March 12, 2025, 9:25am UTC](https://community.fibery.io/t/done-editable-lookup-fields/8424/5 "2025-03-12T09:25:38Z")
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. > [@Lookups are visible to those with no access, but not rich text](https://community.fibery.io/t/lookups-are-visible-to-those-with-no-access-but-not-rich-text/8305): > > 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. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [March 12, 2025, 11:29am UTC](https://community.fibery.io/t/done-editable-lookup-fields/8424/6 "2025-03-12T11:29:46Z")
> [@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. ---
**Author:** ![RonMakesSystems](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/ronmakessystems/32/14122_2.png) [@RonMakesSystems](https://community.fibery.io/u/RonMakesSystems)\ **Post date:** [March 12, 2025, 12:16pm UTC](https://community.fibery.io/t/done-editable-lookup-fields/8424/7 "2025-03-12T12:16:07Z")
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. > [@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](https://drive.google.com/file/d/1WBaSzQJqx8z8OI2k840zIJfYhyFUG2vC/view?usp=sharing)** > > Google Drive file. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [March 12, 2025, 12:35pm UTC](https://community.fibery.io/t/done-editable-lookup-fields/8424/8 "2025-03-12T12:35:44Z")
> [@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. > [@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(!) > [@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. ---
**Author:** ![danielbmarsh](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/danielbmarsh/32/13104_2.png) [@danielbmarsh](https://community.fibery.io/u/danielbmarsh)\ **Post date:** [March 12, 2025, 3:47pm UTC](https://community.fibery.io/t/done-editable-lookup-fields/8424/10 "2025-03-12T15:47:16Z")
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) > [@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. > [@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. > [@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. ---
**Author:** ![RonMakesSystems](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/ronmakessystems/32/14122_2.png) [@RonMakesSystems](https://community.fibery.io/u/RonMakesSystems)\ **Post date:** [March 12, 2025, 4:26pm UTC](https://community.fibery.io/t/done-editable-lookup-fields/8424/11 "2025-03-12T16:26:17Z")
> [@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. ---
**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\ **Post date:** [March 13, 2025, 1:50pm UTC](https://community.fibery.io/t/done-editable-lookup-fields/8424/12 "2025-03-13T13:50:54Z")
1000% this! 🤩 > [@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. ---
**Author:** ![RonMakesSystems](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/ronmakessystems/32/14122_2.png) [@RonMakesSystems](https://community.fibery.io/u/RonMakesSystems)\ **Post date:** [March 13, 2025, 11:06pm UTC](https://community.fibery.io/t/done-editable-lookup-fields/8424/13 "2025-03-13T23:06:23Z")
Just found its related to this: > [@FRQ: Database Inheritance](https://community.fibery.io/t/frq-database-inheritance/4528): > > Hi, For certain types of databases (i.e. Tasks, People, Organisations, Tools) I would like to have the ability to inherit/extend databases. For example: I want a base database called Person which has a few basic fields: given name, surname, email, phone, etc. I’ll have database called Staff that extends Person, which in addition has fields like: join date, role, salary, etc. I’ll have a database called Contact that extends Person, which adds fields like: company, meetings, etc. I’ll have a d… I thought I’d giving it a shot with automations. You can copy the space: > **[Login](https://shared.fibery.io/sign-up?appShareId=7f0af885-0698-41a5-81de-afaef775b769-database-inheritance)** > > Log in into your Fibery account. Build your company workspace with no code. 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” ---
**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\ **Post date:** [April 2, 2026, 2:04pm UTC](https://community.fibery.io/t/done-editable-lookup-fields/8424/14 "2026-04-02T14:04:59Z")
released today > [@parrot April 2, 2026 / Show Fields from relation without Lookup, AI Integration Agent](https://community.fibery.io/t/april-2-2026-show-fields-from-relation-without-lookup-ai-integration-agent/10679): > > potted_plant Show Fields from relation without Lookup Now you can display Fields of related Entities on Views. Here are a couple typical use cases: On a Table View with Contacts, display columns for Contact → Company → State and Contact → Company → Revenue to understand how rude you can be nice you should be to each person. On an Entity View for Employees, show Employee → User → Vacations to save yourself a click. Unlike Lookups, these related Fields: are editable; respect acces…