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)?
I think read-only access for guests is in the pipeline:
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
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 :
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
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
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
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.
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.
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.
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?
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:
This is important for Pricing because:
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.
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 
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?
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.
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.
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.
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.
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.
Good point. Always best to keep things simple if there is no great benefit from complication.
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).
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.
