Now you can, for example, safely share a Projects and its Tasks (but not Allocations) using a public link. Check out the guide for the new mechanism.
The old links will continue to work as is until the end of April 2026, then we will migrate the remaining ones using Viewer access template. Check out the difference between the old and the new mechanism and the suggested migration options in our transition guide.
New names for access levels
Today, we’ve renamed access levels so that they are consistent across Space, Database, and Entity levels.
We’ve accumulated plenty of accidental complexity over the years (e.g., Editor having different permissions on Space vs. Entity level), and now it’s time to get rid of it.
The changes don’t affect the actual access, only the names: no one has lost the capabilities they had or gained new capabilities. There are no action items for you and no reason to panic . Sorry for the kerfuffle, though.
Check out what got renamed to what (and why) in our guide.
Improved File Fields support in automations
We’ve added proper support for File field in automations, and some new use cases opened up:
File field added as a trigger, so you can react to new files addition (or deletion) in automations
In Actions you can now copy Files from one entity to another. For example, you receive new Email from a potential candidate and copy all attached files to the Candidate entity via formula ( note that copy action will replace all existing files, it is pure copy of the whole collection)
In buttons you can set Ask User for Files fields, and it means you can also attach files manually in Send Email action (or select files to attach via a formula)
Yay for “We’ve added proper support for File field in automations, and some new use cases opened up: … In buttons you can set Ask User for Files fields, and it means you can also attach files manually in Send Email action (or select files to attach via a formula)”
This is the most exciting feature released for me. Although I’m no longer hiring, it seems that I’ll be able to share a job description without revealing all applicants.
EDIT: It looks like the new sharing no longer defaults to the same entity layout as the sharer. The link is tied to the default view (which has internal data). I think it should be standard that we choose the entity layout to share when creating a link.
I’d love to see more “how Fibery Uses Fibery” examples of the releases.
I’m often wondering if there are friction points or areas of optimization that can be resolved but I just don’t know how other people are using Fibery
This is nice! One issue I’m seeing. I’m not sure how it decides which view or fields to show. It does not match either our “first” view (the one on the left of the views bar) or the view that’s open when initiating the share. Though the link opens in a single column view, it doesn’t match any of our single column entity views.
For clarification, if the “Contributor” will be decommission on May 2026, what will be the equivalent for this use case?
We have part-time developers, and currently they are given contributor roles based on the task assigned to them only. If “Commenter” is for comment only, can we use the “Editor” role for a “Free Contributor” user license?
Like, how should be create this setup without incurring additional seat license for this kind of users?
Also, the “Users” database, still use the Admin, Member, Contributor (Free) user roles. Will this be updated as them?
Access levels
Contributor is (soon was) an access level for Spaces that involves being able to Create and Update. It can’t be granted to a Guest (because it works at the Space level) and it can’t be granted to an Observer (because they can’t create or update)*
*technically, an Observer could be part of a user group that has Contributor access, but they will be inhibited from actually creating/updating
See here for how access levels are currently named and what they allow.
So for this:
I’m not sure what you’re asking. There is no such thing as a ‘Free Contributor’ user licence (and never was).
You could share specific entities with your part-time developers as Guests (free licence). However, the ability to grant access based on assignment is not supported for Guests, so you would have to share entities manually.
Alternatively, you could pay for Member licences and auto-share (including using custom access templates) any entities you like.
However, needing to make this decision has always been the case, and is unrelated to the renaming of levels or the decommissioning of the Contributor access level.
Not having control over what layout is used when sharing is a major obstacle for me in using this feature. Is there some documentation on this that we missed?
That’s an oversight on our part. I’ll come back once we have a solution. Be sure that we’ll find one that is (at the very least) not worse than the legacy one (:
I tested this again yesterday, and this time it did use the “first” view (which is what I was expecting). Perhaps there was just some glitch early on after the public sharing change.
I’ll just mention that this behavior isn’t really my preference. I’d rather be able to use the first view as the default for internal/workspace work (for our non tech-savvy colleagues), and set the view for public sharing via some other means (either through a formula or a separate “view for public sharing” UI). But it’s at least good to have the original behavior for now.
The first Entity View had been and is now used for public sharing, so no regression here.
Choosing which Entity Views to expose in public sharing turned out to be significantly trickier than I expected (due to selection rules and Views’ lifecycle), so we’ve postponed this until we see more demand.
So, if you notice that some Entity View other than the first one is used for public sharing, it’s a bug for us to fix — please reach out via support in this case.
If you want more control over which Entity Views are exposed to the web, do what @helloitsehas done and tell us — ideally describing your use case.