Guide
In this guide, we’ll walk through how to set up a simple but effective access model — one that reflects how most service or project-based businesses operate.
Let’s say you manage work for multiple customers. Each customer has several projects. Every project includes tasks to complete and invoices to send.
✅ Use Cases this covers:
A customer can see only their own projects, tasks, and invoices — never anyone else’s.
Finance or admin teams can still have full access as needed.
By combining entity relations with Fibery’s flexible permissions, you can neatly map your customer relationships and project workflows, while ensuring that sensitive project data stays properly scoped.
Let’s dive into how to set this up!
Database setup
We’ll work with four databases: Customer, Project, Task, and Invoice.
Each Customer can have multiple Projects, and each Project links to multiple Tasks and Invoices. Access is managed primarily at the Customer level — when a user has access to Customer's card, they automatically inherit access to its related Projects, Tasks and Invoices. This structure can easily be extended if needed, for example by adding Subtasks under Tasks, additional financial entities under Invoice, or custom fields to fit your specific workflow.
Creating Access template
Here you can read what are access templates - Custom Access Templates for Sharing Entities
Please, note, that this functionality works on Pro and Enterprise plans only.
Here is how our template (created on Customer database) looks like:
In short:
Access flows like this:
Customer ➔ Projects ➔ Tasks & Invoices
As a result, you only need to manage access at the Customer level, and the system automatically ensures that users only see the Projects, Tasks, and Invoices belonging to Customers they have permission for.
The Customer Access template defines how permissions are inherited across related databases. Access starts at the Customer level and flows down through related entities:
Customer
This is the top-level entity where access is directly assigned.
A user with access to a specific Customer automatically gains access to that Customer’s Projects, Tasks, and Invoices.
Projects (linked to Customer)
When a user has access to a Customer, they inherit access to all Projects under that Customer.
There’s no need to assign Project access separately — it is fully controlled by the Customer relation.
Tasks (linked to Project)
Since Tasks are children of Projects, and Projects are children of Customers, access to Tasks is inherited through both levels.
This means users can only see Tasks if they have access to the parent Project (which they get via Customer).
Invoices (linked to Project)
This setup is flexible and can be extended. For example, you can add Subtasks (under Tasks), Payments (under Invoices), or additional relations - and permissions will continue to follow the same parent-child inheritance logic.
You can also exclude any level, for example revoke access to Invoices anytime
Permissions indicators
Each level shows different types of access:
Here customers would be able to view and comment any level
However Tasks were granted Edit access - maybe your Customer wants to make some changes, for example, change Tasks priority
You are very welcome to configure access for every database on your own
Apply the template
Now we can use the template.
The Customer Access template defines how access is inherited across related databases (Customer → Projects → Tasks → Invoices), but it doesn't assign access to anyone by itself.
By applying the template to the People field (which connects Users to specific Customers), you’re telling Fibery:
"When a user is linked to a Customer via this field, automatically give them access to this Customer (with View & Comment rights), and propagate that access down to related Projects, Tasks, and Invoices according to the template."
Note, that you can assign as many customer representatives to their card, as you need 🙂
Amazing! Now entity-permissions are ready, and we have to make sure that our customers can see their data the way that makes sense to them.
Proper visualization and Spaces access
We are organizing customer access using two separate Spaces to ensure both security and convenience.
Internal Space: this space contains all core databases and views relevant for our internal team’s work. Customers will have No access by default.
Customer Space: this space contains only curated views that are specifically designed for customer needs. It does not include any full databases. Customers will typically have Contributor or Editor access here, enabling them to interact with the views as needed (e.g., add comments, update allowed fields, or collaborate on specific tasks), while they will have access to their data only.
This structure allows us to provide customers with meaningful and safe access to the information they need, while protecting core data structures and maintaining clear separation of internal and external operations.
Thanks to the access templates, each customer will only see their own data in the Public Space.
Customer's space default access:
Internal's space default access:
Invite customers - to pay or not to pay?
When inviting customers to the workspace, you can assign different roles depending on the level of access they need:
Member:
Customers invited as Members may have full edit and create capabilities (depending on permissions set).
This role allows customers to contribute actively, update records, create new items where permitted, and collaborate more deeply.
⚠️ Note: Inviting customers as Members will require purchasing a license for each Member account.
Observer:
Customers invited as Observers will have view and comment access only.
They can review data and leave comments but cannot create or modify records.
This role does not require an additional paid license, making it a cost-effective option for customers who only need visibility into their data.
What else?
The flexible permission model allows you to safely collaborate with external contributors by controlling exactly which data each person can access. Here are some ideas for you:
Freelancers and Contractors
Provide limited access to the projects or tasks they are directly working on. Freelancers can contribute content, update assigned records, or collaborate, while sensitive or unrelated data remains hidden.
Partners and Vendors
Enable external partners (e.g. logistics providers, suppliers, agencies) to access only the data relevant to their services — such as assigned orders, shipments, or campaigns — while keeping the rest of your workspace fully protected.