- Versão do manual
- 1.12.0
- Aplica-se à versão Klarun
- 2026.09
- Última atualização
- 24 de setembro de 2026
Documentation
Everything you need to set up, configure, and use Klarun, your data team's operating system.
This documentation covers all six modules (Reporting, Governance, Platform, People, Projects, and FinOps), the 360 Assessment, Organization Settings, and the Roles system. Use the sidebar to jump to any section.
What is Klarun
Klarun is a Data Ecosystem OS, a single platform that gives data leaders and their teams full operational visibility over every layer of their data organization: the reports they produce, the assets they govern, the people they manage, the platform they run, and the investments they make.
It is designed for CTOs, heads of data, and BI managers who need to operate at scale without the overhead of custom tooling. Rather than spreading context across Notion pages, spreadsheets, and disconnected BI portals, Klarun centralizes it, and connects to the tools your team already uses (Power BI, Databricks) to pull live data automatically.
Klarun follows a hybrid input model: some data is imported automatically through integrations, while other data is registered manually by your team. Both types live in the same interface and can be enriched, tagged, and acted upon in the same way.
Module Summary
Klarun is organized into six modules. Each module covers a distinct area of your data operation.
Starting with Klarun
Follow these steps when setting up Klarun for the first time. The order matters, because organization settings and integrations unlock data that later steps depend on.
Go to Settings → Organization. Fill in your organization name, industry, company size, fiscal year start month, and timezone. These values power FinOps reports and benchmark comparisons.
Still in Settings → Organization, register your company email domain. Once verified, anyone with a matching email can join via an invite link, with no one-off codes required.
Go to Settings → Membership and generate an invite link. Choose multi-use (whole team), email, domain, or single-use types. Assign roles before or after members join.
In Settings → Integrations, connect Power BI and / or Databricks. Once connected, Klarun syncs all reports and assets from those platforms automatically. Integrations require the Business plan or higher.
In Reporting → Report Catalog, your synced reports will appear immediately. Enrich them with Domain, Subdomain, Owner, and Schedule. Manually register any reports from other tools.
In People → Data Team, add every member of your data organization. Complete profiles (role, squad, seniority, skills, and languages) to unlock People Ops workforce analytics.
In People → Onboarding, upload documents, paste links, or write text notes in each of the eight onboarding sections. New joiners access everything from this page.
In Platform → Architecture, document your data layers and infrastructure components, and expand the Business Domains section at the top of that page to map your domains. In Platform → Health, add any ongoing incidents.
Assets are synced from integrations. In Governance → Contracts & Sources, add your data source contracts and SLAs. In Governance → Data Quality, log active quality issues.
In FinOps → Budget & Plan, enter your budget per platform and category. In FinOps → Actual Cost, record actual monthly spending. Cost Intelligence then computes budget vs. actuals automatically.
In Projects → Objectives, create your strategic goals. Link Key Results to each objective, then create Initiatives (the concrete work items) on the Initiatives kanban.
Free Plan
Klarun offers a free plan that lets you get started without a credit card. It is designed for small teams exploring the platform or for organizations that primarily need the core Reporting module.
- 5 data-team seats
- Core reporting module
- Basic data governance
Reporting
The Reporting module is the central registry for all reports, dashboards, and data products in your organization. It gives every stakeholder a single place to find what exists, who owns it, how often it refreshes, and where to open it. The Operational Cockpit sits on top of the catalog as a live summary of reporting activity and health.
Pages: Operational Cockpit, Report Catalog, Maturity Benchmark
Reports enter the catalog in two ways: automatic sync from connected integrations (Power BI, Databricks), or manual registration for any other tool.
Report Catalog fields
Governance
The Governance module provides a unified view of your data ecosystem's health: all platform assets, their quality status, and the contracts governing your data sources.
Pages: Observability Hub · Assets · Data Quality · Contracts & Sources
Assets are populated automatically from Power BI and Databricks integrations, with no manual entry needed. They are enriched with health flags (broken, orphan, stale) computed from integration metadata. Because assets depend on integrations, the Observability Hub and Assets pages require the Business plan or higher.
Contracts & Sources are entered manually. Each contract represents a data source your organization depends on. Fill in the fields below to track obligations and risk.
Contract fields
Quality issues are logged manually. Each issue captures the affected asset, description, severity, owner, and resolution status.
Platform
The Platform module is where you document the infrastructure your data team runs on and track its operational health. It covers architecture documentation, business domains, platform health, and a maturity assessment.
Pages: Architecture · Health · Assessment
Architecture is an inventory, not a diagram. It is divided into fixed sections, one per layer of the stack, and you register each tool, system, or workload you run as an entry inside the section it belongs to.
Architecture sections
Every entry captures more than a tool name. Fields are grouped so that each workload records who is accountable for it, how heavily it is used, what it costs, and how it is secured.
Business Domains are registered in the Business Domains section at the top of the Architecture page. Tick the domains your data is organized around, or add your own. Domains are referenced across Reporting, Governance, and People.
Health incidents are logged with a title, severity (P1 to P4), a category (availability, performance, freshness, data quality, access or cost), the affected service, description, and current status: Open, Investigating, Monitoring (fixed, watching) or Resolved. Update the status as the incident progresses; the first move out of Open is recorded as the acknowledgement time, which is what mean time to acknowledge is measured from. The affected service is chosen from the Architecture registry rather than typed, so renaming an entry keeps its incident history and two entries that share a name stay distinct. Picking one suggests a severity from that service's business criticality, which you can override. Every change of status, severity, assignee or service is appended to the incident's history, which is written by the platform and cannot be edited. Marking an incident Resolved requires resolution notes and a resolved time that is not earlier than the start time, because those two fields are what MTTR is calculated from. A P1 or P2 additionally requires a root cause category and either a preventive action or an explicit "no preventive action needed": those are the incidents most worth learning from and the ones most likely to be closed in a hurry.
Assessment is a guided maturity questionnaire. Answer the prompts to produce a platform maturity score and a set of recommended next steps.
People
The People module is the hub for your data organization's human layer. It combines a team registry, workforce analytics through People Ops, and an onboarding resource library.
Pages: People Ops · Data Team · Onboarding
Data Team profile fields
People holds no salary or compensation. Pay is recorded only in FinOps, under Actual Cost.
Onboarding sections
The Onboarding page is organized into eight fixed sections. Admins populate each section with documents, links, or text content.
Resource types
An admin can narrow a member's People role to Themselves and their reports, in Settings → Membership under the People roles. The member then reads only their own team member record and everyone under it in the reporting line, directly or indirectly. Data Team shows how many of the whole team they are seeing, and the org chart starts at them.
The line starts from the team member record linked to the member's Klarun account. With no linked record, with two, or when the reporting line loops back to them, the member sees nobody, and Settings shows a warning next to them. Managers are checked on every change, so a new loop cannot be saved. The change applies on the member's next request and is recorded in the audit log. Organization admins are never narrowed.
Projects
The Projects module is Klarun's OKR (Objectives and Key Results) framework. It gives data teams a structured way to define their strategy, track measurable outcomes, and manage the concrete work items that deliver on those outcomes. The Portfolio gives a high-level view across all objectives and initiatives.
Pages: Portfolio · Objectives · Key Results · Initiatives · ROI Evaluator
Start top-down: create Objectives first, then add Key Results to each one, and finally create Initiatives under Key Results.
An admin can narrow a member's Projects role to Only what they own, in Settings → Membership under the Projects roles. Reading does not change: the member still sees every objective, key result, and initiative, so the Portfolio and the progress roll-ups stay whole. What narrows is what they can change.
An initiative's contributions move the progress of the key results it links. So a narrowed member cannot link, unlink, or change a contribution to a key result they do not own, even on an initiative they own. Those links stay as they are.
Ownership comes from the team member record linked to the member's Klarun account, and each account can be linked to one record only. With no linked record, or with two, the member can change nothing, and Settings shows a warning next to them. The change applies on the member's next request and is recorded in the audit log. Organization admins are never narrowed.
FinOps
The FinOps module gives data leadership the financial visibility they need to run the data function as a business. It covers budget planning, actual cost tracking, and a Cost Intelligence overview that compares the two.
Pages: Cost Intelligence · Budget & Plan · Actual Cost
Budget & Plan: Add budget lines for each data platform (e.g. Databricks, Snowflake, Power BI) broken down by cost category and month. The fiscal year calendar is driven by your Organization Settings → Fiscal Year Start.
Actual Cost: Enter or import actual monthly spending for each platform and category. On Corporate plans and above, AI assist can parse uploaded invoices and payroll into structured monthly rows.
Cost Intelligence reads from your budget and actuals and computes variance automatically. No separate data entry is required on this page.
FinOps data is split into three sections, each shared all-or-nothing on top of the FinOps role. The role sets how much a member can do in FinOps; the sections set which parts of it they see.
With nothing chosen, FinOps admins hold every section and everyone below admin holds Platform and Projects, so payroll is always an explicit grant. Organization admins always hold every section. An admin changes a member's sections in Settings → Membership, under the FinOps roles. The change applies on the member's next request and is recorded in the audit log.
Figures that add sections together, such as the combined budget and variance on Cost Intelligence and the FinOps figure on the Cockpit, appear only for members who hold both Platform and Team. Opening or deleting a fiscal year and changing the fiscal-year start need every section. The 360 Assessment shows its finance section only to members who hold every section.
360 Assessment
The 360 Assessment is Klarun's AI-powered organizational review. It synthesizes data from across your modules (Governance, Platform, People, Projects, and FinOps) into a single, periodic assessment of your data organization's health, with narrative insights and recommendations.
Pages: 360° View
There is no manual data entry. Keep the other modules up to date, then generate an assessment for a period. The quality of the result depends on how complete your Governance, Platform, People, Projects, and FinOps data is.
Organization Settings
Settings are accessible from the sidebar under your organization name. The page is divided into four tabs: Organization, Integrations, Membership, and Billing. Users with the org_admin role can modify every setting. The org_member role can manage the Organization, Integrations, and Membership tabs, but not Billing, and cannot grant the admin role.
Organization tab
Configure your organization profile. These values appear throughout the app and power features like FinOps and benchmarking.
Domain verification
Register your company email domain to enable domain-based invite codes. Anyone with a matching email address can then join your workspace using a domain invite link, without needing a one-off code.
Verification is done via a one-time code sent to an admin email on the registered domain. Once verified, the domain is locked and used for all future domain invites.
Integrations tab
Connect your BI tools to Klarun. Synced integrations automatically populate Reports (Reporting module) and Assets (Governance module).
Power BI setup steps
Go to Azure Portal → Microsoft Entra ID → App registrations → New registration. Give it any name (e.g. "Klarun Integration"), select Single tenant, and click Register. Use a dedicated registration: do not reuse the one connected to Microsoft 365 Copilot.
Leave API permissions empty. Do not add Tenant.Read.All, and do not grant admin consent. Power BI refuses a service principal that carries admin-consented Power BI permissions in Entra, and the call then fails with a 401 that reads like a credential problem. Access is granted in the Power BI admin portal instead, in steps 03 and 04.
Open Power BI Admin Portal → Tenant settings → Developer settings. Enable "Service principals can call Fabric public APIs". This covers workspace and report listings. If you scope it to a security group, add the service principal to that group.
Power BI Admin Portal → Tenant settings → Developer settings → Service principals can call Fabric public APIsIn the same portal, open Tenant settings → Admin API settings and enable "Service principals can access read-only admin APIs". This is a separate switch from step 03 and covers tenant-wide metadata, lineage and usage. Scope it to a group the service principal belongs to, then allow about 15 minutes for both settings to take effect.
Power BI Admin Portal → Tenant settings → Admin API settings → Service principals can access read-only admin APIsBack in the app registration → Certificates & secrets → New client secret. Set an expiry and click Add, then copy the Value column immediately. Do not copy the Secret ID, which sits beside it and is not a credential. The Value is shown only once.
Go to Settings → Integrations → Power BI → Connect. Enter your Tenant ID, Application (Client) ID, and the Client Secret value. Click Test connection, and if successful, click Save & sync.
Databricks
Connect one or more Databricks workspaces using a personal access token and workspace URL. Once connected, Klarun syncs notebooks, pipelines, and ML assets as Governance assets and enriches the Report Catalog with Databricks-backed reports.
Membership tab
Manage who belongs to your Klarun workspace. You can view all current members, change their roles, and create invite codes.
Invite code types
Billing tab
View your current plan and manage your subscription. Upgrading, downgrading, and entering payment details are all handled from this tab. Only users with the org_admin role can access the Billing tab.
Roles
Klarun uses a layered role system. Every member has one org-wide role that controls baseline access across the entire workspace, plus optional module-specific roles that grant elevated permissions within individual modules.
Org-wide roles
Assigned at the workspace level. Apply to all modules unless overridden by a module-specific role.
Module-specific roles
Each module has three tiers: admin, contributor, and viewer. Module roles are additive: assigning a module role to a member grants that permission level for that module regardless of their org-wide role.
Permission matrix
Baseline permissions by role tier, applicable across all modules. Module admins have the same privileges as org admins within their module scope. Exception: in People and FinOps, creating, editing, and deleting records needs the admin tier, and FinOps is further divided into sections (see FinOps sections). In Projects, an admin can limit a member to changing only what they own (see Edit only what you own), and in People to themselves and their reports (see Themselves and their reports). Anyone whose Klarun account is linked to a team member record can edit their own skills and languages.
Data Access Scopes
Roles decide what a member can do in each module. Data access scopes narrow which of that module's records they reach. A scope only ever narrows a role: it never grants access the role does not give, and organization admins are never scoped. Scopes belong to each member, are set by an admin in Settings → Membership next to the roles they narrow, and are enforced on the server on every request, for the pages and the API alike.
The three scopes
Each scope is described in full with its module: see FinOps sections, Edit only what you own, and Themselves and their reports.
When a scope cannot be worked out
The Projects and People scopes start from the team member record linked to the member's Klarun account. Each account can be linked to one record only, and an admin can link a record to their own account only when the record's e-mail is theirs. When the link is missing or doubled, or when the reporting line loops back to the member, the scope gives nothing rather than guessing: in Projects the member can change nothing, and in People they see nobody. Settings shows a warning next to the member so an admin can fix the record. Managers are checked on every change, so a new loop cannot be saved. A stored scope that cannot be read is treated as the narrow choice.
Everywhere the data appears
A scope follows the data rather than the page, so the same rules apply wherever that data is shown.
Audit
Every scope change is recorded as admin.scope_changed, naming the member, the admin, and the new value for each module it touched. Every change to the account a team member record is linked to is recorded as people.link_changed, and role changes remain admin.role_changed. A scope change applies on the member's next request without signing them out; a role change signs them out of every session, so it applies at once. Admins who manage Settings can read the audit trail.