Guide
Unlike regular Views, context Views visualize data for a particular Entity and can be mirrored to avoid double work. Create context Views in Smart Folders or use Relation Views to visualize to-many relations on Entity View.
When context Views are useful?
Consider using context Views in these two cases:
a View is relevant for a particular Entity only:
CJM Whiteboard for a specific Feature;
an ad-hoc Report for a specific Client;
…
the same kind of View is needed for a few Entities of the same Database:
Roadmap for every active Product;
Contacts Table for every Client;
…
Context Views in a Smart Folder
Smart Folders are a great way to build custom navigation in the sidebar based on your most important Entities such as Products, Clients, or Teams. Once you've created a Smart Folder, create context Views for the Entities inside:
On a context View, you can only visualize DBs reachable via context filters. If you need a completely unrelated DB, create a regular View instead.
If a context View has already been created elsewhere (e.g. in another Smart Folder or a doc), look it up instead of recreating one from scratch:
Mirroring a context View
If some kind of View is useful for all Entities in a Smart Folder, create and configure a View for any Entity and then mirror it for all the others:
Mirroring replicates the same View for every Entity and keeps all the versions in sync. For example, if you add custom sorting, this will automatically be reflected in all the mirrors — you don't have to update each copy manually. The data on each mirrored View is automatically filtered based on the relevant Entity.
Here are a few typical examples when mirroring a context View comes in handy:
List of Key Results for current Objectives;
Historical $MRR Report for highest paying Customers;
Vacation Calendar for all Employees.
Only data Views such as Tables and Boards can be mirrored: Documents or Whiteboards with their unique content cannot be replicated automatically.
Context filters
The data on a context View is filtered automatically. By default, we apply the most straightforward context filter but you are free to select another one or disable the automatic filtering altogether:
The context filter options include different ways to reach the DB being visualized from the DB of the context View's parent Entity via Relations. We traverse many-to-one (e.g. Features to Product) and many-to-many (e.g. Segments to Clients) relations, including those populated by Formulas and Lookups.
Imagine you have three DBs related in this way:
In this case, a context View for a Niche allows you to visualize either the Competitors linked directly or those linked to the Niche's Use Cases.
One-to-many relations (e.g. Product to Features) are excluded when calculating possible context filtering options. If the context filter option you are looking for is missing, please let us know in the chat — we'll find a workaround while bumping the priority for out-of-the-box support.
Context Views permissions
Unlike regular Views, every context View belongs to a specific Entity or, when mirrored, to a Database. This implies different permissions to create, manage, and access them:
| Non-mirrored | Mirrored |
👀 to see in the sidebar and navigate via a direct link | read access to the parent Entity
| Any of the two suffice: Note: anyone (incl. Guests) can see mirrored context Views in top-level Smart Folders. |
✏️ to create, configure, and delete | edit access to the parent Entity
| configure access to the parent DB (e.g. via Architect)
|
🎣 to display in/remove from a certain Smart Folder | 👀 + ✏️ |
🪞 to mirror/unmirror | Both required: |
Relation Views: context Views on Entity View
Every to-many relation on an Entity View can be visualized using a set of Relation Views:
Relation Views are fully functional mirrored context Views, so you can apply custom grouping, sorting, and color-coding — as you would on any other View. By default, we offer a simple List View, but you can customise and even replace it with a View of a different kind — for example, a Table or a Timeline.
Disable linking Existing entities in Context Views
In some workflows, you usually create new entities instead of linking existing ones — for example, Time records linked to Projects or Expenses linked to Shipments.
Fibery now allows you to disable linking existing entities in Context List Views:
Open the Items view in your Context List.
Toggle off “Allow linking existing entities”.
Once disabled, users will only be able to create new entities, simplifying your workflow and avoiding accidental links to existing records.
FAQ
How permissions are applied for Context reports?
Who can see a mirrored report in a Smart Folder?
Any user can see a mirrored report if they have access to the Entity that this Report belongs to.
Data is displayed as if the report owner is viewing it.
Users do not need direct access to the database used by the report, but the report owner must have access.
What happens if the report owner loses access or is inactive?
If the report owner no longer has access to the underlying data, users will see “Access Denied”.
This happens even if the user otherwise has access to the Smart Folder or report.
Do we need to recreate existing reports?
No. "Mirrored reports" automatically operate on behalf of the master report owner.
However, if the original report owner has lost access or has been changed, the report may stop working correctly for other users. In this case:
Suppose you want to share a Context Report. Context Reports are generated per-entity, meaning each view has its own internal copy of the Report. When shared, this per-entity copy may show some inconsistent results, which is why sharing the Context report is not recommended.
If you need to share a Report, create a standalone one specifically for sharing.