Contexts
A Context is a business-domain label — for example Marketing, Finance, or Sales — that you attach to Data Marts, Storages, and Destinations to group them by domain and to control which members can see them.
Contexts are managed by Project Admins from Project Settings → Contexts. Once a context exists, it can be:
- attached to any Data Mart, Storage, or Destination in the project, and
- assigned to project members to scope their visibility (see Roles and Permissions).
☝️ Contexts are project-scoped. Each context belongs to a single project and is not shared across projects.
When to Use Contexts
Section titled “When to Use Contexts”Use Contexts when you need to give different teams access to different subsets of project resources without giving every member project-wide visibility. Typical examples:
- A Marketing context groups all marketing-related Data Marts, the Storage they read from, and the Destinations that publish marketing reports.
- A Finance context does the same for finance assets, kept separate from marketing.
A member assigned only to the Marketing context will see Marketing-tagged resources but not Finance ones (subject to the rules in How Contexts Affect Access).
If every member should see every resource, you don’t need Contexts — leave each member’s role scope set to Entire project.
Managing Contexts
Section titled “Managing Contexts”Only Project Admins can create, rename, or delete contexts. Other roles can view the context list and see context badges on resources, but cannot create, rename, or delete contexts.
Open Project Settings → Contexts to see all contexts in the project. Each row shows:
| Column | Description |
|---|---|
| Name | The context label shown on resources |
| Members | Members assigned to this context |
| Description | Optional Markdown description with business goals and Data Mart links |
| Created by | The Project Admin who created the context |
| Created at | Creation date |
Creating a Context
Section titled “Creating a Context”- In Project Settings → Contexts, click + Add context.
- Enter a Name (required, up to 255 characters; must be unique within the project).
- Optionally add a Description to explain what the context represents.
- Optionally select members to assign to this context immediately.
- Click Create.
You can also create a context inline from the Contexts field on a Data Mart, Storage, or Destination — a Project Admin sees an option to create a new context without leaving the resource page.
Editing a Context
Section titled “Editing a Context”In the contexts list, click a row (or use the row actions) to open the Configure context panel. From there you can change the name, description, and the set of assigned members. Changes apply immediately to all resources tagged with this context — the context’s identity is preserved, so attachments remain intact.
Business descriptions and Data Mart links
Section titled “Business descriptions and Data Mart links”The description editor supports Markdown and a Preview tab. Use the formatting toolbar to insert headings, bold or italic text, links, lists, quotes, code blocks, and tables without typing the Markdown syntax yourself. Type @ and search by title to select an accessible published Data Mart. Each entry shows the Data Mart’s icon. Then choose Link entire Data Mart or a specific output-schema field. Search fields by alias or technical name; calculated fields are included and marked in the list. Fields without an alias use their technical name. Hidden fields, including hidden calculated fields, and disconnected warehouse fields are not offered for reporting references. Calculated fields remain available regardless of their warehouse connection status. The Data Mart icon also appears before its link in Preview. The same editor is available in Project Settings → Overview → Description and on a Data Mart → Overview.
Press Escape in the field picker to return to the Data Mart list. Press it again to close the picker and keep editing the description, including literal text after @. Moving the caret through an existing @ does not reopen the picker. Tab closes it when focus moves to another control. In a Context editor, these actions keep the panel open and preserve your draft.
When editing a Data Mart’s description, the current Data Mart is omitted from @ suggestions. Project and Context descriptions can reference any accessible published Data Mart.
The link stores the Data Mart’s project and resource IDs in its URL. Renaming the Data Mart keeps the link working; its written label stays as it was when inserted. Deleted or inaccessible Data Marts remain subject to the normal resource access checks.
A mention is a reference, not a context assignment. To attach a Data Mart, use its Contexts picker. Inserting a link never changes attachments, membership, or access permissions. A field reference stores the Data Mart title and field alias as its readable label, and the field’s technical name in the URL as ?field=.... Opening it expands Output Schema, scrolls to the exact field, and highlights its row. For nested fields, the parent records expand too. If the field is renamed or removed later, the link still opens the Data Mart normally, without highlighting a different field or applying a search. The saved label and technical name stay unchanged; update the reference manually when necessary.
Use descriptions to explain goals, terminology, and which Data Marts supply relevant measurements. Connected AI assistants receive the complete Markdown through MCP: get_project_context for Project, list_contexts for Context, and the Data Mart discovery/details tools for Data Mart descriptions. All project members can view context descriptions; only Project Admins can edit them.
In the Project and Data Mart descriptions, click Edit description, then Save to persist changes or Cancel to discard them. Selecting a suggestion or switching to Preview does not save the description. Context descriptions are saved with their existing Create/Save form.
Deleting a Context
Section titled “Deleting a Context”A context can only be deleted when it is detached from every resource and member. If a context is still attached, the delete is blocked and the dialog lists the attachments that need to be removed first:
- N Data Marts
- N Storages
- N Destinations
- N Members
Each entry links to the corresponding list, pre-filtered by the context, so you can detach attachments quickly.
☝️ Deleting a context is final, but it does not delete the resources tagged with it. Resources stay; only the tag is removed.
Attaching Contexts to Resources
Section titled “Attaching Contexts to Resources”Contexts can be attached to Data Marts, Storages, and Destinations. Each resource can carry any number of contexts, and a context can be attached to any number of resources.
You manage attachments from the resource itself:
- Data Mart → Contexts card on the Data Mart overview page
- Storage → Contexts section in the Storage settings form
- Destination → Contexts section in the Destination settings form
In each place, the Contexts picker shows every context defined in the project; check the ones that apply.
Resource lists (Data Marts, Storages, Destinations) display attached contexts as badges, and the lists can be filtered by context.
Who Can Change a Resource’s Contexts
Section titled “Who Can Change a Resource’s Contexts”Editing a resource’s context attachments is more restricted than editing the resource itself. The rules follow the same ownership model as other resource actions (see Ownership and Sharing):
| Resource | Who can edit attached contexts |
|---|---|
| Data Mart | Project Admin, or Data Owner with the Data Owner role |
| Storage | Project Admin, or Owner with the Data Owner role |
| Destination | Project Admin, or Owner (any role) |
Members who can edit a resource for other reasons (for example, a non-owner with the Data Owner role editing a Data Mart that is Shared for maintenance) cannot change its contexts unless they meet the rules above.
Assigning Members to Contexts
Section titled “Assigning Members to Contexts”Member–context assignment is the link that turns Contexts into an access-control mechanism. There are two equivalent ways to manage it:
- From a member — open Project Settings → Members, edit a member, and pick contexts in the Contexts section.
- From a context — open Project Settings → Contexts, edit a context, and pick members in the Members section.
Both paths write to the same assignment, so changes made in one place are reflected in the other.
☝️ Assigning a member to a context only takes effect when their Role scope is set to Selected contexts only. See the next section.
How Contexts Affect Access
Section titled “How Contexts Affect Access”Each non-admin member has a Role scope, set in Project Settings → Members:
| Role scope | Effect |
|---|---|
| Entire project | The member sees every shared resource in the project, regardless of context assignments. This is the default. |
| Selected contexts only | The member sees a shared resource only if the resource is attached to at least one of the contexts the member is assigned to. |
Project Admins always have project-wide access. The role-scope setting and context assignments are not applied for admins.
☝️ Ownership overrides context filtering. A member always sees resources they own — Data Owner of a Data Mart, Owner of a Storage or Destination — even if no context overlaps, and even if their scope is Selected contexts only.
What “Selected Contexts Only” Applies To
Section titled “What “Selected Contexts Only” Applies To”The context filter applies to non-owner visibility of:
- Data Marts
- Storages
- Destinations
- Reports (visibility follows the parent Data Mart, as documented in Ownership and Sharing)
Triggers do not have their own visibility — they follow their parent (Data Mart or Report).
Members Assigned to Zero Contexts
Section titled “Members Assigned to Zero Contexts”A member with role scope Selected contexts only and no contexts assigned is a valid state. They simply have no shared, non-owner access through context matching. They keep access to anything they own.
What Changes When You Re-Tag a Resource
Section titled “What Changes When You Re-Tag a Resource”Adding or removing a context on a resource immediately changes who can see it:
- Adding a context to a resource grants visibility to every Selected contexts only member who is assigned to that context.
- Removing a context revokes visibility for any such member who relied on that context for the overlap (provided no other context overlap remains and they are not an owner).
Related
Section titled “Related”- Managing Project Members — invite members, change role and scope.
- Roles and Permissions — what each role can do, independent of contexts.
- Ownership and Sharing — the other two layers that determine resource access.