# \[DONE\] Read-only guest users?

**URL:** <https://community.fibery.io/t/done-read-only-guest-users/1527>\
**Category:** Ideas & Features\
**Tags:** permissions\
**Created:** [April 4, 2021, 9:03pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527 "2021-04-04T21:03:34Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**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:** [April 4, 2021, 9:03pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/1 "2021-04-04T21:03:34Z")

</div>

Is it possible to have read-only guest users for (part of) a workspace?

Also, is it possible to embed a specific View into an iframe somewhere else, which would actually be a live view (i.g. with collaborative editing, showing real-time updates, etc)?

---

<div class="post-metadata">

**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:** [April 4, 2021, 11:04pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/2 "2021-04-04T23:04:15Z")

</div>

I think read-only access for guests is in the pipeline:

> **[\#30. Baby Steps in February 2021](https://fibery.io/blog/chronicles-30/)**
>
> Many demos for product teams. Product Teams A/B Test. Complexity. Other niches experiments paused. New roadmap. Hierarchical Lists View released.

🙂

---

<div class="post-metadata">

**Author:** ![Polina\_Zenevich](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/polina_zenevich/32/480_2.png) [@Polina\_Zenevich](https://community.fibery.io/u/Polina_Zenevich)\
**Post date:** [April 6, 2021, 1:14pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/3 "2021-04-06T13:14:55Z")

</div>

Hi, Matt!  
Read-only viewers are in the roadmap definitely and development started. Arrival terms (not a promise) - 2-3 months 📅  
If this is a must for you now and you don’t want to pay for them - you can ping us in the intercom and we will find a workaround 🙂

> Also, is it possible to embed a specific View into an iframe somewhere else, which would actually be a live view (i.g. with collaborative editing, showing real-time updates, etc)?

That request is pretty common, so we have that in the backlog although not sure about ETA

---

<div class="post-metadata">

**Author:** ![Simon\_JB](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/simon_jb/32/1453_2.png) [@Simon\_JB](https://community.fibery.io/u/Simon_JB)\
**Post date:** [August 4, 2021, 11:43am UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/5 "2021-08-04T11:43:37Z")

</div>

Hello, just bumping up this thread to see if this feature is still on the roadmap 🙂

For Product Management teams, it is likely that there will be a few editors that manage the backlog, roadmaps etc on a day to day basis ; and a lot of stakeholders that might need to look at the roadmap or release plan (or even the entity details !) on a read-only basis.

As a Product Consultant i still hesitate to recommand Fibery to my bigger customers as to share the roadmap broadly (which is a good thing in any org) you need to create accounts for everyone which is a. too costly and b. messy in terms of permissions.

Now that we have entity-sharing and document-sharing, it seems to me the missing piece is either :

- view sharing (with a read-only link, same thing as documents and entities)
- guest accounts, with the ability to restrict which view they get access to.

Are you waiting for the Blocks idea to be done (in which case views might be embedded into entities and it will solve the problem) or planning to add view sharing before then ?

Thanks

---

<div class="post-metadata">

**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:** [August 4, 2021, 11:59am UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/6 "2021-08-04T11:59:41Z")

</div>

This is in nearest future plans. There is no dependency on blocks. However before this we are going to implement better Views permissions to start “My Space” section in Fibery. Then we’ll get back to Free Read-only users.

[https://community.fibery.io/t/roadmap-features-we-are-working-on-or-will-work-on-soon/1879/2](https://community.fibery.io/t/roadmap-features-we-are-working-on-or-will-work-on-soon/1879/2)

---

<div class="post-metadata">

**Author:** ![Simon\_JB](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/simon_jb/32/1453_2.png) [@Simon\_JB](https://community.fibery.io/u/Simon_JB)\
**Post date:** [October 22, 2021, 8:44am UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/7 "2021-10-22T08:44:54Z")

</div>

Looking forward to the feature 🙂 it is proving to be a real blocker for customer adoption vs tools like Product Board.

Last week again I was talking to a customer about using fibery for their roadmap, and the first question they asked was “can I share this view to the stakeholders”?

It might help also for your “Partner Program” to sell the solution

---

<div class="post-metadata">

**Author:** ![rothnic](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/rothnic/32/1850_2.png) [@rothnic](https://community.fibery.io/u/rothnic)\
**Post date:** [October 22, 2021, 3:56pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/8 "2021-10-22T15:56:51Z")

</div>

> [@Simon\_JB](#):
>
> Looking forward to the feature 🙂 it is proving to be a real blocker for customer adoption vs tools like Product Board.

I agree. We have been waiting in limbo since may or so without being able to move forward on any real adoption because of it. Fibery is still a toy we play around with sometimes because we can’t share everything from it within our organization and there is no way we could afford a full account for everyone.

One thing to note is the whole read-only thing isn’t the best approach to begin with. I really prefer Coda’s pricing compared to the other options for an organization like ours. They have Creators that can setup and modify the docs and tables within the docs, which go up in price as you need more enterprisey features/packs. The people that are just consuming or using the apps/docs that exist are all free, which means that it is easier to get adoption from a full org.

 ![image](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/d/d5e32d37527fd2e628a713a84631f88a32982bdf.png)

---

<div class="post-metadata">

**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:** [October 22, 2021, 4:17pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/9 "2021-10-22T16:17:08Z")

</div>

To be honest I don’t think Coda pricing model is sustainable in the long run. I expect they will rise prices in the near future.

As for read-only users, we are finalizing the whole permission model concept now and start implementation next week. It was an EXTREMELY difficult problem, since with all this flexibility there are many cases that we wanted to cover. I still can’t give any ETA, but on a positive side a team of 2 will be working on this full time now.

---

<div class="post-metadata">

**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\
**Post date:** [October 22, 2021, 4:53pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/10 "2021-10-22T16:53:37Z")

</div>

> [@Simon\_JB](#):
>
> Last week again I was talking to a customer about using fibery for their roadmap, and the first question they asked was “can I share this view to the stakeholders”?
> 
> It might help also for your “Partner Program” to sell the solution

I agree, this could be huge. The pricing of tools like Productboard and Canny is insane to me for what they do, at least as compared to something like Fibery. Once Fibery is able to do public roadmaps, feature voting, and change logs, it could open up a whole new market.

---

<div class="post-metadata">

**Author:** ![Simon\_JB](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/simon_jb/32/1453_2.png) [@Simon\_JB](https://community.fibery.io/u/Simon_JB)\
**Post date:** [October 22, 2021, 5:33pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/11 "2021-10-22T17:33:11Z")

</div>

Great to hear @mdubakov! Thanks for the update!

I agree on coda’s pricing. It feels very very generous, bordering on unsustainable (even if good for users). I’m also not sure the distinction between a maker and a user is immediately understandable to everyone. I know when they announced their pricing I had to read the thing two or three times juste to grasp it : so i can add data to this table, but not change the text that is above it nor create a new one?

Coda’s model also does seem ill-fitted to fibery. There’s no “document as app” to speak off, unless you’re saying only the person configuring the app should pay and everyone else in the org getting to use the app for free? Would be nice for me, not so for fibery’s bottom line with only one or two pair accounts per customer ^^

Essentially having either open shareable link to a view, Google docs-like (bonus if can be protected with a password) or free guest users with limited permissions would fit the bill for me, and probably others?

---

<div class="post-metadata">

**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:** [October 22, 2021, 6:55pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/12 "2021-10-22T18:55:29Z")

</div>

Personally, I see both the need for fine-grained control over permissions (entity-based and view-based), AND the need for flexible pricing based on different roles.

**Example:**

- All 200 of our employees need _limited_ access based on their roles - some just need read-only access plus commenting/messaging.
- 20 employees need “editor” level access to different specific areas (create new entities and edit existing).
- 4 employees need admin-level access to everything.
- 200 outside clients need very limited access to specific entities and views. Ideally, these users can be given read-only access to some views and entities, and additionally have the ability to create and collaboratively edit _certain specific entities/fields_ (e.g., create/edit/view specific fields in trouble-ticket entities, add text to a RichText field in Meeting Notes entities and participate in Commenting/notifications).

This is important for **Pricing** because:

- we would not be able to afford paying the “full” seat price for all of these users.
- we would gladly pay a lower price for a large number limited users, because of the value that it would add.

---

<div class="post-metadata">

**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\
**Post date:** [October 22, 2021, 7:08pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/13 "2021-10-22T19:08:05Z")

</div>

Because per-field permissions seems insane to me (how about you? 😄), I wonder if the idea of multiple layouts/views/tabs per-Type could solve your needs _if_ those layouts could themselves be permissioned. So you could then just create a view specific to customers that showed only the data they should see and be able to edit.

If you wanted to show values without making them editable by everyone who can otherwise edit data in that layout, then perhaps the existing concept of a “Lookup from” field could be used, but looking up from the Type you are editing (and the value thus being transcluded or instantiated in read-only mode).

Or I guess it could just be its own type of simple permissions per-field that just specifies read or read/write globally, not per-user or based on any permissions lookup. In other words you instantiate a field shown on another layout of that Type, and you get to choose if it’s read/write or read-only _on that layout_. Thus anyone who has access to that layout can only read that field _on that layout_, if you so choose. Anyone who needs to edit that field could use a different layout where the field itself is read/write.

I’m curious if this makes sense to you, or if you have a better solution in mind.

---

<div class="post-metadata">

**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:** [October 22, 2021, 7:55pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/14 "2021-10-22T19:55:04Z")

</div>

> [@Oshyan](#):
>
> I wonder if the idea of multiple layouts/views/tabs per-Type could solve your needs _if_ those layouts could themselves be permissioned. So you could then just create a view specific to customers that showed only the data they should see and be able to edit.
> 
> If you wanted to show values without making them editable by everyone who can otherwise edit data in that layout, then perhaps the existing concept of a “Lookup from” field could be used, but looking up from the Type you are editing (and the value thus being transcluded or instantiated in read-only mode).

Yes, I think that is a good solution for this particular need. 👍

The ability to have custom entity views & dashboards is going to be a game-changer for Fibery 😃

---

<div class="post-metadata">

**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:** [October 22, 2021, 8:41pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/15 "2021-10-22T20:41:41Z")

</div>

> [@Matt\_Blais](#):
>
> **Example:**
> 
> - All 200 of our employees need _limited_ access based on their roles - some just need read-only access plus commenting/messaging.
> - 20 employees need “editor” level access to different specific areas (create new entities and edit existing).
> - 4 employees need admin-level access to everything.
> - 200 outside clients need very limited access to specific entities and views. Ideally, these users can be given read-only access to some views and entities, and additionally have the ability to create and collaboratively edit _certain specific entities/fields_ (e.g., create/edit/view specific fields in trouble-ticket entities, add text to a RichText field in Meeting Notes entities and participate in Commenting/notifications).

I’m curious to hear what you think a fair price to pay (total per month) would be for the usage you’re describing here?

---

<div class="post-metadata">

**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:** [October 23, 2021, 3:25pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/16 "2021-10-23T15:25:56Z")

</div>

> [@Matt\_Blais](#):
>
> - All 200 of our employees need _limited_ access based on their roles - some just need read-only access plus commenting/messaging.
> - 20 employees need “editor” level access to different specific areas (create new entities and edit existing).
> - 4 employees need admin-level access to everything.
> - 200 outside clients need very limited access to specific entities and views. Ideally, these users can be given read-only access to some views and entities, and additionally have the ability to create and collaboratively edit _certain specific entities/fields_ (e.g., create/edit/view specific fields in trouble-ticket entities, add text to a RichText field in Meeting Notes entities and participate in Commenting/notifications).

When we introduce free read-only users (with commenting option as well), it will solve some of these problems.  
The next step can be to introduce cheap, but limited access users. For example, limit an access to just 1 App and charge $5/user/month. We will never restrict fields access, it will be extremely hard to implement.

---

<div class="post-metadata">

**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:** [October 23, 2021, 3:30pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/17 "2021-10-23T15:30:07Z")

</div>

> [@Matt\_Blais](#):
>
> - 20 employees need “editor” level access to different specific areas (create new entities and edit existing).
> - 4 employees need admin-level access to everything.

I don’t think we should differentiate pricing for admins and normal users. Let’s say, we will make Fibery cheaper for non-admins, like $7 per user, but more expensive for admins, like $20 per user.

Now you will pay for 24 users around $240/month (above initial price). But with this new model it will be $140 + $80 = $220, so the difference will be marginal, but it will complicate pricing scheme.

---

<div class="post-metadata">

**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:** [October 23, 2021, 4:33pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/18 "2021-10-23T16:33:14Z")

</div>

I agree that there is no single, best solution for everyone, as everyone has different needs and different ideals. And it does not make sense for you to spend lots of effort and complicate the product unless there is real benefit.

One extreme would be to charge for actual metered usage (CPU & storage).

At the other extreme is just one single plan with no flexibility - certainly that would disappoint many customers, but is simpler to understand and easier to implement.

> [@mdubakov](#):
>
> When we introduce free read-only users (with commenting option as well), it will solve some of these problems.

That will work for many cases, if these free users are still subject to permissions that can restrict their views, and the notification system also works for them.

> [@mdubakov](#):
>
> … cheap, but limited access users. For example, limit an access to just 1 App and charge $5/user/month.

A user with access to only a single app is not ideal, because it really changes how I have to think about designing my Workspace. But it is a good direction. I would prefer a different structure, perhaps a user with **write access to just one or two views**.

The ideal for my own case would probably be metered usage some limited users, since I expect that mostly they will use very little. But I know that is problematic and hard to sell.

---

<div class="post-metadata">

**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:** [October 23, 2021, 4:36pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/19 "2021-10-23T16:36:19Z")

</div>

> [@mdubakov](#):
>
> I don’t think we should differentiate pricing for admins and normal users. Let’s say, we will make Fibery cheaper for non-admins, like $7 per user, but more expensive for admins, like $20 per user.
> 
> Now you will pay for 24 users around $240/month (above initial price). But with this new model it will be $140 + $80 = $220, so the difference will be marginal, but it will complicate pricing schem

Good point. Always best to keep things simple if there is no great benefit from complication.

---

<div class="post-metadata">

**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:** [October 23, 2021, 5:14pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/20 "2021-10-23T17:14:28Z")

</div>

> [@Matt\_Blais](#):
>
> I would prefer a different structure, perhaps a user with **write access to just one or two views**.

I don’t think it will be possible to implement easily. View in Fibery is just a window to the data and it can be very dynamic. Imagine you change one filter and instead of 5 entities a user now sees 1000. It is possible to implement, but so far we are hesitant to move into this direction. We want to rely on more stable structures (app, type, entity).

---

<div class="post-metadata">

**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:** [October 23, 2021, 8:34pm UTC](https://community.fibery.io/t/done-read-only-guest-users/1527/21 "2021-10-23T20:34:48Z")

</div>

> [@mdubakov](#):
>
> we are hesitant to move into this direction. We want to rely on more stable structures (app, type, entity).

I’m sure this can also work well for my needs, when coupled with **per-entity permissions.**

So I will create an App just for my “external client” users, with specific Types in this app which are their sole access to our system, consisting of Relations to any fields in other apps that they need write access to, and Lookups to other fields that they should only have read-access to.

With per-entity permissions, this is a workable solution; but without it, every client user is able to see every entity exposed through this app - e.g., they can see our other clients’ entities as well as their own.

I do need per-entity permissions to limit these “client users” to _only have access to their specific entities_. Otherwise I would need to create a separate app for every such user, and that quickly becomes unwieldy.

[Next page](https://community.fibery.io/t/done-read-only-guest-users/1527.md?page=2)
