Sharing
Sharing is a first-class feature in Lakehousecat. Every major object — from data sources and models to charts, dashboards, prompts, and sessions — can be shared with individual users or entire groups. Recipients get precisely scoped access based on a configurable permission level, with no need for them to recreate or duplicate anything.
What Can Be Shared
| Object | Share with Users | Share with Groups |
|---|---|---|
| Data Sources | Yes | Yes |
| Models (Custom) | Yes | Yes |
| Charts | Yes | Yes |
| Dashboards | Yes | Yes |
| Sessions | Yes | Yes |
| Job Definitions | Yes | Yes |
| Prompts | Yes | Yes |
Permission Levels
When you share an object, you assign a permission level to each recipient. The available levels depend on the object type (see Per-Object Permissions below).
| Permission | What the recipient can do |
|---|---|
| Read | View the object and its contents. Cannot make any changes. |
| Write | View and modify the object. Cannot delete it or manage who has access. |
| Share | View, modify, and share the object further with other users or groups. |
Owner is the permission level of the creator. It grants full control including deletion and permission management. Owner is set automatically and cannot be assigned through the sharing dialog.
In the sharing dialog, clicking the permission badge of a selected recipient cycles through the available levels in order.
How to Share an Object
The sharing workflow is identical for all object types:
- Navigate to the list view of the object (e.g., Workspace → Analytics → Charts).
- Hover over the item you want to share.
- Click More (⋯) → Share.
- The sharing dialog opens with two tabs: Groups and Users.
- Use the search bar to find a group or user.
- Click a result to add them as a recipient. They are added with Read permission by default.
- Click the permission badge on a recipient to cycle to a higher permission level if needed.
- To remove a recipient, click the × on their entry.
- Click Save to apply all changes.
The object immediately appears in the recipient's Shared with Me section.
Viewing Shared Objects
Every list view in the workspace includes three sections:
| Section | Who sees it | What it contains |
|---|---|---|
| My [Objects] | The owner | All objects you have created |
| Shared by Me | The owner | Objects you are currently sharing with others |
| Shared with Me | Recipients | Objects others have shared with you |
The Shared by Me section shows you at a glance what you have actively shared and with whom.
Revoking Access
Remove a specific recipient
- Open the sharing dialog again (More (⋯) → Share).
- Click × on the user or group whose access you want to remove.
- Click Save.
Revoke all shares at once
- Go to the Shared by Me section.
- Hover over the shared item.
- Click More (⋯) → Unshare.
This removes all recipients in a single action.
Sharing with Groups
Sharing with a Group grants access to every current member of that group simultaneously. When users are later added to or removed from the group, their access to all objects shared with that group updates automatically — no re-sharing required.
Groups are managed in Workspace → Access → Groups (Admin only).
When to use groups vs. individual users:
| Situation | Recommendation |
|---|---|
| Sharing with a stable team | Group — membership changes propagate automatically |
| Sharing with a single specific person | Individual user |
| Sharing across departments | Group — easier to maintain at scale |
Per-Object Permissions
Different object types expose different sets of permission levels in their sharing dialogs:
| Object | Read | Write | Share |
|---|---|---|---|
| Data Sources | Yes | Yes | — |
| Models (Custom) | Yes | Yes | — |
| Charts | Yes | Yes | Yes |
| Dashboards | Yes | Yes | Yes |
| Sessions | Yes | Yes | Yes |
| Job Definitions | Yes | Yes | Yes |
| Prompts | Yes | Yes | Yes |
Data Sources and Models intentionally omit the Share permission to prevent uncontrolled redistribution of sensitive infrastructure resources.
Sharing Custom Models — Data Access Implications
Sharing a Custom Model is not just an organizational action — it is a data access decision. Users who receive access to a Custom Model can query all data that the model exposes through its linked data sources and semantic layer.
When you share a Custom Model, the recipient gains the ability to query all data the model has access to — including every table, column, and row that passes through the Data Source and Custom Model filters. The recipient does not see the raw data source configuration, but they can ask natural language questions that retrieve, aggregate, and display that data in a session.
Before sharing any Custom Model, explicitly verify:
- Which data sources are linked to the model
- Which tables and columns are visible after filtering
- Whether any sensitive data (HR, payroll, financial, personal data) is within scope
- Whether the intended recipients are authorized to access that data under your organization's data governance policies
The data access chain
Understanding who can access what requires tracing the full chain:
Technical User (DB credentials)
│
▼ connects the data source
Data Source (with DS-level filters)
│
▼ Builder applies DS filters — controls what is loaded
ClickHouse (loaded data)
│
▼ Builder creates Custom Model, links data sources, applies CM filters
Custom Model (exposes a specific perspective)
│
▼ Builder or Admin shares the Custom Model
User Group or Individual User
│
▼ queries the model in a session — sees the data
The technical user who set up the database connection may have a restricted database role — but the data that passes through the Data Source filter is fully accessible to anyone who receives the Custom Model. The Custom Model is the access boundary for end users.
Sensitive data scenarios
If a Data Source connects to an HR database, a payroll system, or any other classified data store, even a broadly filtered Custom Model that includes only a few tables from that source can expose sensitive information to all recipients. Consider the following before sharing:
| Question | If yes: |
|---|---|
| Does the model's data include personal data, salaries, or medical information? | Treat the share as a classified access grant. Use groups with controlled membership. |
| Are some columns in scope that shouldn't be visible to all recipients? | Apply Custom Model column filters to exclude them before sharing. |
| Is the recipient group large or poorly defined? | Use a named, role-specific group rather than a broad group. Review membership before sharing. |
| Could the data scope change after sharing (e.g., a data source is reconfigured)? | Re-review what the model exposes after any filter or data source change. |
Builder responsibility
Builders have the power to create Custom Models and share them with users. This makes the Builder role a data steward role in practice — not just a technical configuration role. The Administrator should ensure that Builders understand the data they work with and the implications of the models they share.
Administrators retain full visibility into what is shared and with whom via the Audit Log in the Access section.
Object Visibility and the Sharing Model
Every object in Lakehousecat has an owner — the user who created it. Newly created objects are visible only to the owner by default. No other user can see or access the object until the owner explicitly shares it.
This applies to all object types: data sources, models, charts, dashboards, sessions, prompts, and job definitions.
To make an object visible to others, use the Share action and add the intended recipients with the appropriate permission level.
Recommended Sharing Hierarchy
For Custom Model-based workflows, the recommended pattern is:
- Administrator defines Provider Models and shares them with Builders
- Builders create and validate Custom Models using those Provider Models
- Builders share Custom Models with the User circles who need access
- Users query the Custom Model in sessions and generate charts/dashboards
- Builders or Users share charts and dashboards as needed
This hierarchy ensures that data access decisions are made deliberately at the model level before content reaches end users.
Chart and Dashboard Sharing — Access Dependency
Sharing a Chart or Dashboard does not automatically grant that user access to the Custom Model the chart was built from. If the user does not have access to the Custom Model, they will receive an access denied error when trying to view the chart.
Before sharing a chart or dashboard, verify that all intended users also have access to the Custom Model it was created from.
Why this matters
When a User creates a chart from Custom Model X and shares it with Group B, Group B members need two things:
- Access to the shared chart (provided by the share action)
- Access to Custom Model X (must be configured separately)
If Custom Model X has not been shared with Group B, the chart will be visible in their Shared with Me section but will fail to load.
Data exposure risk
This dependency also creates a data exposure risk in the reverse direction: if a User shares a chart built from a Custom Model that Group B should not have access to, and then also grants Group B access to that Custom Model — Group B gains full query access to the model's data, not just the shared chart.
Sharing a chart to a group effectively requires granting that group access to the model's full data scope. Review the Custom Model's data scope carefully before granting access.
Access Requirements
For a recipient to access a shared object, they need:
- A valid Lakehousecat account
- Membership in the shared group (for group-based shares)
Users who receive a share but are not yet registered receive no access until they have an active account.
Object-Specific Sharing Details
For detailed instructions on sharing within each feature area, refer to the individual guides: