[DONE] Publish Fibery Space to the Web

It seems you need per-entity permissions more for this case. Space-per-client is quite heavy and the problem here is databases proliferation. For 10 clients you will have 10 spaces and most likely 50+ different databases. I don’t think this is a good solution. With per-entity permissions you can separate access by Client entity and all linked entities will be visible per-client only.

Not sure, it looks like a personal problem, and we are looking for teams problems more.


Can you provide some details? What are the flows?

Current solution will not rely on record-level access unfortunately, so I am not sure your case will be solved in an efficient way. Free read-only users will be released soon (and a bit later we will add Comment permissions to them as well), but still without per-entity access it will be hard to invite them.

1 Like

For me this whole thread is just about making something visible to external parties - notion do this quite well IMO. In sharing info with external folks you very often don’t want people changing things but you might want to capture peoples comments or feedback - and I wouldn’t want to pay for people to just view and comment on somthing.

The only caveat to the above is when I conduct stakeholder workshops to capture information on jobs to be done, pains, gains, need them to do things like stack rank problems to be solved etc etc.

These workshops need to be collaborative and get people involved in the process rather than just sharing a screen with them and me doing it for them. This is where making the whiteboard more ‘editable’ by external users would work well. Everyone loves a sticky note right?

These stakeholders are not going to be regular users of the system so again I would be reticent to pay for them to just use it on an adhoc basis. Mural / Miro allow for this.

Hope this helps.


Got it, thank you! It is relatively easy to implement, we will take this into consideration

1 Like

If you guys move forward on this, I would find these aspects in particular useful:

Some time ago we looked at an Atlassian guide on how to use Confluence as a public-facing User Guide and it looked intriguing.

However, and I’m probably in the minority, I’d much rather see you guys prioritize some other stuff, much of which I’d call the “rough edges” of Fibery, before doing work on publishing a Fibery space to the web. My team uses Fibery for work management, and could really use some simple improvements that would avoid the daily frustrations in Fibery, before we have the ability to publish to the web, which won’t help our daily quality of life:

  • Improved commenting and Notifications - discussed in various areas here already
  • Fix of multitude of formatting bugs: Odd key combos, such as trying to paste in comments commits them; trying to add referenced entities when doing a soft return “shift” + “Return” puts the reference on another line, and a host of others
  • Inability to create an inline entity 100% using the keyboard when typing “#”. The last few steps you can do when creating a new entity straight from the “ctrl” + “K” command with the keyboard do not work when creating inline
  • Can’t see closed entities in search, but you can see them when referenced around Fibery with the strikethrough, and you can see them grayed out in Collections when typing in those fields. So it’s odd that you can’t see them in the search dialog. Request is here: Seeing “Closed” Entities grayed out in Search Dialog
  • Would much rather see Bi-directional integrations/sync before pushing data to the web. Without this, I don’t really think the Fibery integrations are true “integrations,” but rather API connections that are custom built for user ease-of-use
  • Dashboards - This is a feature all of my team looks for, because they expect it, but it doesn’t exist.
  • Ability to create a Context View and see multiple locations of the same Entity in the cards. Context views are a very useful feature (I’m talking about filtered views that adjust for each entity in an App based on the filter). Example of this: I have a Sprint DB. I have stories connected to it. The stories have tasks. However, in each sprint I want to do some one-off tasks that don’t belong in a Story. I can set up a board that will update with each new Sprint via these Context Views. However, I can only see one “type” of the Tasks due to this limitation: Either the ones directly related to the Sprint, or the ones in Stories that are in the Sprint via lookup. This is a limitation that hurts us in various areas of Fibery, and would also be solved with Polymorphic relations. When creating relation, ability to have many Types from which to choose, and not just one Type that also would be something I’d like too see completed before pushing the Fibery Space to the Web
  • Whiteboards do not yet represent real relations. I have stopped using them for over a year waiting for this feature, as they are not useful without this. Without better integration with Fibery entities, the Whiteboard are more or less just a way to diagram within Fibery, but you can do this more elegantly with other apps, some free, and just embed into Fibery. I really hope you guys realize the potential of integrating Whiteboards with Fibery Entities. One of my favorite features of Fibery is actually the self-created “map” in the Workspace Map. Even if something like that could self-create inside apps it would be a hugely helpful feature.

I hope you guys don’t come down on me as in the past when I posted feedback, but you are asking these questions:

So I’m trying to answer all three of those!

Cheers and keep working hard to get Fibery complete (and I know most of what I mentioned above you will deliver at some point!)

1 Like

I think this would be AWESOME :sparkling_heart:

My own primary use case would make good use of #2but it would also require per-entity permissions scoped by user. “Full users” = our employees, and “free/limited users” = our clients.

If per-entity permissions are not available for this kind of “free/limited user” access, an equally good alternative for my case would be a lower-cost “limited user” – but I know that is tricky to define in a way that makes sense in general.

For example my “free/limited users” (our clients) would have access only to specific views and specific entities (i.e. only those related to that client), plus editing or commenting ability in some of those, and also the ability to create some others (e.g. tickets).

I don’t know how to define this in a general way that makes sense, because these “free/limited users” appear to need all the same access and capabilities as regular users, but limited to specific views and entities. It looks very arbitrary.

For my case at least, it is only the “business perspective” that wants to make a distinction between limited users (our clients) and regular users (our employees); because our clients will make much less use of Fibery than our employees, so there is the natural desire from the business perspective to pay less for their access. But it is quite difficult to make a clear distinction from the technical side. This is why “charging by usage” can look like a good option for some cases from the customer’s point of view.

1 Like

This sounds like a big system to develop (allowing people to “sign up”, etc. in particular), so while I could definitely see some significant possible value, I would also not want to see it detract much from other long-standing requests, as @B_Sp notes. That said I am not sure that it is so much work, and I am curious why you are proposing it. Perhaps because you have realized it could be done fairly easily and may be of good value for your users.

My use case seems like a pretty classic software dev team one, where change log and docs would be a great start, but overall feedback management (let’s set aside “replacing the forums” in entirety for the moment), feature requests and bug reports in particular, would make it especially appealing. To do that it would need to allow for front-end submission (new entity, e.g. feature request), potentially an approval queue (front-end submissions should not necessarily just show up publicly right away), and a way for people to react/vote on and ideally comment on things. If these features could be enabled on a per-“type” basis (e.g. reactions enabled for Docs or Change Logs, but no comments, comments and reactions enabled for feature requests, etc.), the that would be ideal.

As I touched on at the beginning, what I find surprising about much of what is suggested here in the original proposal is that it clearly encompasses e.g. Native Forms & Conditional Workflows using Tripetto SDK, at least in part, or Form View and required fields. Yet that received only cautious confirmation for some unspecified future time from Fibery team to-date. Assuming that this overall feature set outlined above would require a lot of work above and beyond that, it seems like a bit of a departure from core focus, despite its potential utility to many teams…

So I am curious to hear from @mdubakov to clarify the potential dev time on this. Maybe I have assumed too pessimistically.

1 Like

Thank you for supporting my comments, and this is a great point you make! Would also like to hear details about 1) the origin of this potential feature vis a vis other high priorities here in the community, and 2) how much dev time the team thinks it will take them to release.

I am not sure this is relevant to Publish Space feature. Your case should be resolved with Free read-only users (with comments ability and maybe some Add Entity ability) + per-entity permissions. As far as I understand, you will invite clients as guests and will not publish any Space.


In general this idea is relatively easy to implement for read-only cases (user guide, changelog, etc), but not so easy for community/feedback collection. Indeed to complete these harder cases we will have to have Forms, registration, etc.

Form View is one of the top request, but it has a blocker (permission on Views). Now it is close to completion and at least it will open this feature for real consideration. So we will see.

So far only read-only publishing is in spike mode, we will not dig into more complex cases till Forms and better permissions.


We need it totally. Our actual use cases.


We’ve started the first feature


It would awesome to see more of this implemented, especially the external users feature!

I’ve been using Fibery as a project management solution for an electrical :zap: service company. Currently I use it for:

  • Information organization (client and job info)
  • Material ordering/management
  • Task Mangement

While it works very well for those tasks, I’ve always wanted to add some sort of client dashboard and scheduling feature. I’ve tried Calendly and even gone so far as to try and integrate it with Fibery with Integromat, but it never really worked as intended. My dream would be able to make something on Fibery to do the same job. The format would be as follows:

  1. New client signs up/existing client logs in.

  2. The landing page shows all of the projects for a given client (entities) and gives them an option to request a new project (add new entity).

  3. The projects (entities) could show waitlist order and/or scheduled date, duration, project status, and could be a place for documents/photos or cloud storage links.

  4. Ideally they would also be able to add comments to the projects (entities) and see and potentially edit linked information (contact info).

I actually think I could build something pretty close to this with the current features in Fibery, but I need a way for clients to see only the projects (entities) assigned to them so that the rest of the projects in the database are hidden.

My hope is that between the features in this thread and [PLANNED] Entity-level permissions it might be possible to build this. I don’t know exactly how the add entity/form submission feature would be implemented but I figure it would probably be easiest to make permission control part of the automations. That way you could have blind or read only form submission for feedback uses and editable form submission for collaborative uses. Basically (when user adds entity → add user as read-only/editable). I’m still a little confused about how the linking permissions (for contact info, etc.) might work but it seems like their are some good ideas out there already in other threads.

I’d love :two_hearts: to hear feedback on the idea if there is another product/solution that I’m missing that might be really obvious. Thanks!

1 Like

Hi, in general this is all aligned with our plans.
I recommend to check this use case: open Fibery to the world.

The road to this is relatively short, but hard. Essentially, you need only entity-level permissions (with quite advanced configuration, since you don’t want to show all linked entities most likely, for example, do you want to show all tasks in a project to a client?). Then you can invite people into Fibery as read-only (free) with an option to add comments.

I am not sure that you want allow users to register, but this is also in our future plans for other cases (like product community/feedback/etc).

We are moving into this direction slowly.


Thanks for the reply, the use case seems to exactly cover what I’d need to set this up. I realize that both entity level permissions and external users are hard features to add, I’m just excited that it might ever be possible!

1 Like

Would it be possible to open up for access to read “workflow” field on shared entities or so?
I’d like to share document with entities in it and have the workflow state show.

1 Like

It would be wonderful to have this kind this “Public visibility” control over all fields and DBs.

I suppose that is not something that entity-based permissions would allow, since this is a field-level control. :slightly_frowning_face:

There are no plans for field-level permissions, but it is already possible to hide fields in all types of views now (including entity view).
I suppose you could create a variety of views, each with differently hidden fields, and share them with different stakeholder groups.