# Expose system relations in entity permissions

**URL:** <https://community.fibery.io/t/expose-system-relations-in-entity-permissions/8391>\
**Category:** Ideas & Features\
**Tags:** permissions\
**Created:** [March 6, 2025, 2:59pm UTC](https://community.fibery.io/t/expose-system-relations-in-entity-permissions/8391 "2025-03-06T14:59:35Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**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 7, 2025, 8:10am UTC](https://community.fibery.io/t/expose-system-relations-in-entity-permissions/8391/3 "2025-03-07T08:10:57Z")

</div>

Use case:

Inviting freelancers to write a piece. Then we want to comment internally about said piece before giving the feedback to the client.

Current work around: Automatically create a “thread” entity (that the freelancers has no permission to) linked to the freelancers work. Then chat in there. But that’s quite hidden and is bad UX.

Ideally I just create a comment field in the work itself and don’t give the freelancer access to it.

Use case 2. Client portal has a status field. I don’t want the clients who are shared in the portal to see this status. Workaround: new database and linked with one to many. Downside: worse UX (bc of the arrow to open), and results in a lot of databases.  
If you expose the single and multi select. It essentially gives field permissions (for those types) without much extra dev time.

Lmk if this makes sense. Thanks!

---

_[View the full topic](https://community.fibery.io/t/expose-system-relations-in-entity-permissions/8391)._