Guide
How to share Projects with Customers as Guests
When setting up access for external collaborators, such as clients or contractors, it’s important to choose the right type of user role. In Fibery, Guests and Observers have different access patterns and intended use cases:
Guests are ideal for external collaborators because they only see items explicitly shared with them. They cannot access the rest of your workspace, ensuring your internal data remains secure. Guests can also edit the specific items shared with them, allowing them to contribute without overexposure.
Observers, on the other hand, are designed for internal team members who need broad visibility but should not make changes. They can see most of the workspace (depending on permissions) but cannot edit anything.
Why Guests then?
Controlled visibility: customers only see what you share with them.
Editable shared items: they can contribute to cards or projects without risking access to internal data.
Security: Guests cannot see other Guests or internal workspace elements, reducing the chance of accidental exposure.
Prepare sidebar for Customers
On the top of your workspace (above spaces), create a Smart Folders
Name it accordingly - for example, Projects.
Inside this folder, you can add views (e.g. Tasks by State, Calendar, etc.) your Customer will be interested in
This Smart Folder will act as the top-level entry point for your customers.
User roles
Guest is not a global role (like Admin, Member, or Observer).
Instead, “Guest” just means: this person has access to some records via sharing.
Guests only see the items explicitly shared with them (plus anything below, if you extend access).
How to invite User as a guest?
Note: only those that are not invited yet to the workspace can be Guests
Open the Project entity you want to share.
Click Share.
Add your customer’s email.
Choose their access level: Viewer, Commenter, Editor, or Owner (or a custom one, see below).
Click Extended Access so they also get access to all related tasks and child entities under the project.
You are also welcome to use Custom Access Templates for Sharing Entities for more granular control!
How to turn Members/Observers into Guests?
If you already invited your customers as Observers or Members, you’ll need to switch them:
Go to Users → Remove them from the workspace.
Re-invite them at the Project level (using the Share button).
Enable Extended Access so they see tasks and related items.
Now they will show up as Guests and only see what they need.
In a nutshell:
Use a Smart Folder as the top-level menu for customers.
Invite customers at the Project level, not the Workspace level.
Enable Extended Access so they see all related tasks.
Guests are not global roles — they only exist where you’ve shared records.
Test the setup before rolling it out widely ❤️
Client Portal Space - another approach
One of the most effective ways to improve client experience — without overcomplicating permissions — is to rethink where clients land when they enter the workspace. Instead of exposing clients to smart folders, internal spaces, or navigation meant for your team, the client portal should be a dedicated Space, not a smart folder.
Why a Space (not a Smart Folder)
A Space gives you something critically important from a UX perspective: control over first impressions.
When a client logs in:
The Space becomes the first thing they see
You can place a clear, intentional dashboard at the top
Navigation feels purposeful instead of overwhelming
Unlike smart folders, Spaces don’t need to contain databases themselves. They can act as a presentation layer — dashboards, views, embedded forms, and curated links — powered by permissions underneath.
This means:
One client portal Space — not one per Client
You do not need a separate Space for every client.
A single Client Portal Space can serve all clients, as long as:
This scales cleanly even if:
A client has multiple users
A client eventually owns multiple Projects
Your business grows without redesigning permissions later
Designing for multiple client users
Instead of granting access “to the person,” access should be granted to the object — for example, the Project.
That way:
One client can invite multiple teammates
Everyone sees the same up-to-date information
You avoid duplicating logic or views
This is especially important for B2B setups where a single customer account often includes several stakeholders.
Observers vs Guests: the practical tradeoff
To make Spaces work for clients, users need to be Observers, not Guests.
Why?
Guests cannot be invited into Spaces
Observers can access Spaces and dashboards
Observers are still free of charge
The tradeoff:
For many client portals, this is an acceptable starting point:
If, in the future, clients need conditional editing (e.g. “can change release date only in certain states”), this becomes a case for:
Let permissions do the Work
Once the Space is set up:
Clients land directly on their dashboard
They only see items shared with them
No custom app or workaround is required
The Space defines experience.
Access templates define rules.
Permissions quietly enforce everything in the background.
Allowing Clients to edit Fields
Sometimes clients need more than just viewing access - they need the ability to manage certain parts of their projects, such as updating release dates or editing specific Project details.
Step 1: Assign Client Users to Projects
Make sure each Project in your system is linked to one or more client users.
This creates a relation that allows Fibery to reference the client users on the episode level.
Step 2: Create a Client Editing Field on Project or any other level
Go to your Project database.
Add a new People field called something like Client Editing Permission.
Enable Multiple People if a Project has multiple client users.
Disable notifications for this field to prevent unnecessary emails.
Set Automatic Sharing so that assigned clients gain edit rights to the project automatically.
Step 3: Populate Client editing Permissions automatically
You need to connect the Client Editing Permission field to the correct users based on Project states.
Approach Options:
Lookup Field: Pull client users from the related podcast. This ensures the clients are always visible in the episode context.
Automation Rules: Use rules to assign or remove clients depending on the episode’s state.
Example Rules:
Project State | Action |
|---|
Submitted | Assign relevant client users to Client Editing Permission field |
In Production | Remove client users to revoke editing access |
This ensures clients can only edit episodes before production, preventing accidental changes later.
Step 4: Maintain and Extend
The system supports multiple clients per Project and multiple Projects per client.
Future updates (e.g., Fibery validation rules) will prevent clients from accidentally changing the Projects state or any other information.
This setup can be expanded to include field-level restrictions for additional databases, giving clients a tailored editing experience without exposing unnecessary data.
Automatically Grant Access to Projects for a Specific Group
Imagine, you want certain projects (e.g. those with the Strategic Theme = Regulations Compliance) to be automatically shared with a specific group of people, such as Legal & Privacy.
Instead of manually applying access templates every time, you’d like an automation that ensures the right people always get access when the project is created or updated.
How to configure it
Create a Relation between Projects and Access Groups
Assign an Access Template on the Relation Field
Automate the Assignment
Good to know:
But by applying the template on the relation field itself, you ensure access is granted at the right level.
The automation only needs to handle assigning the group; the template will take care of permissions.
When a new Regulations Compliance project is created, it is automatically related to the Legal & Privacy group. The relation applies the access template, granting the whole group the correct permissions instantly.
How to share Candidates with related Team (Hiring use case)
When you’re hiring across multiple teams — for example, developers, sales, and operations — it’s often important to keep candidate information visible only to the people who actually need it. A new sales candidate shouldn’t be visible to the dev team, and the engineering applicants shouldn’t appear in the marketing team’s list.
That’s where permissions come in. You can set up your hiring workspace so that each team only sees candidates for their department, while HR or hiring managers retain full visibility. This keeps sensitive data protected, avoids clutter, and ensures everyone focuses only on the candidates relevant to them.
In this guide, we’ll show you how to structure your candidate database and configure permissions so that:
Each team can access only the candidates related to their department.
HR and admins can still see all candidates across teams.
The setup scales easily when new teams or roles appear.
Data structure
For this setup, you’ll only need two databases: Candidate and Team.
The Candidate database stores all the information about applicants — name, contact details, role, interview notes, stage, and any other fields you find useful for your hiring process. You can customize this freely depending on your workflow (or simply use our Hiring template)
The Team database, on the other hand, is more universal. Many companies already have a Team database used for other purposes — if that’s your case, simply reuse it. The key requirement here is that Team must act as a User group. In other words, each Team should have one or more Fibery users assigned to it, and Fibery should recognize this database as a source of permissions.
This connection is what allows you to automatically control who can see which candidates — for example, ensuring that the “Sales” team only sees Sales applicants, and the “Engineering” team only sees Engineering candidates.
(You can read more about how user groups work and how to configure them)
Permissions
In Fibery, permissions are managed on two levels: Space permissions and Entity permissions. Both are important when setting up hiring visibility rules.
A key principle to remember: in Fibery, you grant access rather than restrict it.
That means you can’t say, “Everyone has access to all candidates except these.”
Instead, you define: “No one has access to candidates — unless they meet specific conditions.”
In our case, that condition will be:
“A person has no access to candidates unless they belong to the team that candidate is assigned to, or they are part of HR or Executive management.”
Let’s follow this step by step:
Space permissions:
Your Candidate database lives in the Hiring Space.
Set the default access to this Space as No access for all users.
Then grant HR and Executive teams higher access levels (for example, “Full access” or “Can edit”) — depending on how much control they should have.
You can assign access either to specific users or to entire teams, depending on your company size.
Entity permissions:
For everyone outside HR and Executives, access remains No access by default.
To allow visibility only when relevant, we’ll link each Candidate to a Team through a relation field.
Once the relation is set, enable sharing capabilities, so that every user who belongs to the assigned Team automatically gains access to that candidate.
This approach ensures privacy by default — only HR and the relevant team members will see each candidate, while everyone else remains locked out.
Visibility
Now that permissions are properly configured, let’s make sure everyone can see what they are supposed to — not just have technical access.
HR managers are covered, since they already have full access to the Hiring Space. But what about other teams? By default, since access to the Hiring Space is set to No access, other employees won’t even see this space in their sidebar — meaning they also won’t see any of the views.
To fix this, here’s the trick:
Create a View (for example, a Table or Board) in a Space that everyone can access, at least on the Viewer level — such as the Company Space.
This view will display candidates pulled from the Hiring database, but visibility of individual candidates will still follow the permissions we set earlier.
In other words, the view itself is shared, but the data inside it is filtered automatically based on each person’s access rights.
Scaling
That’s the easiest part — permissions setup in Fibery scales naturally with your company’s growth.
Need to add a new team?
Just create a new record in the Team database and assign users to it — permissions will automatically apply based on your existing logic.
Want to grant someone full visibility across all candidates?
Simply give them direct access to the Hiring space.
Need something more granular?
Use Custom Access Templates to fine-tune visibility rules or create additional propagation logic.
Still not sure how to make it all work perfectly for your setup?
No worries — ping us in chat, and we’ll gladly help you figure it out.
How Guests can create Entities with Public forms
Our primary goal will be to:
Submit new Tasks through a shared public form.
Automatically link each new Task to the correct Project (based on contact email).
Ensure every Task is properly associated with the Client’s Project record.
This guide is a workaround. At the moment Guests can't create new Entities. And Context Forms are not here yet. Thus, we need to use this structure.
Create a Form for Task Submission
Create new View in any Space
New View will be Form view, with Tasks databases a source → name it something like “Task Submission Form.”
Decide which fields you want your Client to fill in
Task Name (text)
Contact Email (email) — this identifies which Client/Project the task belongs to.
(Optional) any other details you’d like submitters to include (e.g. description, due date, priority).
📢 Note:
This form will be shared publicly so that anyone (clients, guests, partners) can submit new Tasks without needing a Fibery account.
Generate link for the public share
Automatically link Tasks to the correct Project
Create a Rule in the Tasks Database
Explanation
Each Project record already has a Client Email (pulled in as a lookup from the Clients database).
The rule looks for a Project whose Client Contact Email matches the Contact Email submitted in the Task form.
When a match is found, the Task automatically links to that Project.
If multiple matches exist, the rule picks the first one alphabetically (you can adjust sorting or filtering if needed, for example, connect to the Active Project).
If you’re working with a Client who has multiple active Projects, using the contact email as the link may not be precise enough. In that case, replace the email as the matching field (anchor) and instead ask the client to enter the Project Name or Project ID in the Task submission form. This ensures each Task is linked to the correct Project.
Test the Flow
Open the Task Submission Form.
Fill in a test example:
Click Submit.
After submission:
A new Task appears in the Tasks database.
The Project field fills in automatically (based on the Client’s email).
The Task is now fully connected to the correct Client → Project chain.
Handle Errors (optional quality check)
To catch any Tasks that didn’t auto-link (e.g., due to incorrect or missing email):
Create a new Table View in the Tasks database.
Apply this filter: Project is Empty
Name it something like “Unlinked Tasks (Fix Needed).”
This makes it easy to spot and fix submissions that didn’t connect to a Project.