> For the complete documentation index, see [llms.txt](https://docs.powermonitor.com.br/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.powermonitor.com.br/en/technical-documentation/documentacao-tecnica/modelo-de-dados.md). # Data Model Main entities of the Power Monitor data model and the Power BI / Fabric artifacts it tracks. This page describes, at a conceptual level, the main information Power Monitor stores about each organization. All data is stored in PostgreSQL, with dates in UTC. ## Isolation per organization * Every entity with customer data belongs to **one organization** (organization identifier stored in each record). * Identifiers are **GUIDs generated by the application**. * The **Entra ID tenant** and the **Power Monitor organization** are different identifiers: the tenant is used to find the organization at sign-in; from then on, all queries are filtered by the organization. ## Main entities ### Organization Represents a customer (a Microsoft Entra ID tenant). | Information | Description | | ----------------------- | -------------------------------------------------------------------------------------------------------------- | | Entra ID tenant | Tenant to which the organization is linked | | Registration data | Trade name, legal name, CPF/CNPJ (Brazilian tax ID) or registration number, country, currency, phone, WhatsApp | | Application credentials | Client ID, Client Secret, and security group, **encrypted** (AES-256 + RSA envelope in Azure Key Vault) | | Installation type | Automatic, manual, or legacy | | Status | **Incomplete** (installation in progress), **Active**, or **Suspended** | | Consents | Terms of use and consent to automatic billing (with date/time and text version) | | Preferences | Selection of monitored workspaces (curation), enabled monitoring, AI provider, notification channels | ### User and profile | Information | Description | | --------------- | ------------------------------------------------------------------------------------------------------------ | | User | Microsoft account from the tenant, role (**User** or **Administrator**), profile, and monthly AI usage limit | | Profile | Set of blocked pages; three default profiles per organization (Admin, Member, Audit) and custom profiles | | Workspace scope | Workspaces the user **can view** and **receives alerts** from | ### Workspace | Information | Description | | --------------------- | -------------------------------------------------------------------------------- | | Remote identifier | Workspace ID in Power BI / Fabric | | Name, type, and state | Active, deleted, orphaned state, etc. | | Capacity and domain | Fabric capacity and domain to which it belongs | | Monitored | Whether the workspace is in monitoring (determines screens, alerts, and billing) | | Deletion detected | Date on which Power Monitor detected the deletion in the tenant | | Governance | Owner, business area owner, area, sub-area, and criticality level | ### Artifacts (items) **34 workspace item types**, each with a reference to the workspace, metadata collected by the Scanner API, and detected deletion date: | Category | Types | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | **Power BI** | Report, Dataset (semantic model), Dashboard, Dataflow, Datamart | | **Storage** | Lakehouse, Warehouse, SQL Database, Mirrored Database, KQL Database, Eventhouse | | **Data engineering** | Notebook, Data Pipeline, Copy Job, Spark Job Definition, Apache Airflow Job, dbt Job, Environment, User Data Function, Variable Library | | **Data science and AI** | ML Model, ML Experiment, Data Agent | | **Real-time** | Eventstream, KQL Dashboard, KQL Queryset, Reflex (Activator), Event Subscription | | **Others** | Exploration, Metric Set, Org App, Ontology, Graph Model, App Backend | Semantic models also store tables, columns, measures, expressions, data sources, size, and schedules. **Tenant-level resources:** capacities, gateways, connections, and Power BI apps. **Derived relationships:** semantic model × connection, dataflow × connection, app × report, and the lineage between items. ### Tasks and schedules | Information | Description | | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Task | Scan or monitoring type, status (**Pending**, **Running**, **Completed**, **Failed**, **Cancelled**), cron expression for recurring tasks, next and last run, progress, result, error message, and attempts (up to 3 by default) | | Capacity schedules | Pause/resume, SKU change, auto-scale rule, and time-window alerts | ### Monitoring | Information | Description | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Resource health state | Current state (Unknown, Healthy, Degraded, Unhealthy), open incident, start and duration, failure and notification counts | | Refresh and run history | Semantic model refreshes and Fabric item runs, with status, duration, and error | | Capacity consumption | Series of interactive, background, and accumulated usage, by capacity, item, and operation | | Anomalies | Baselines and consumption deviations by item | | Costs | Daily cost per capacity | | Alerts | Type, source resource, severity, message, date/time, and delivery | ### Audit | Information | Description | | ------------------ | --------------------------------------------------------------------------------------------------------------------- | | Activity events | Power BI/Fabric events (when collection is enabled): user, operation, item, workspace, IP, and estimated location | | Application events | User actions in Power Monitor: event, resource, route, user, IP, browser, previous and new values, success or failure | | Email log | Emails sent by the platform | | Capacity actions | Pauses, resumes, and scaling performed, with the source (manual, scheduled, or automatic) | ### Billing | Information | Description | | ------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Billing information | Tax details, billing emails, due date, recurrence, onboarding fee installments | | Daily measurement | Number of monitored items per day (with the list of items counted), flagging the days of the trial period | | Charges | Monthly fees and onboarding fee installments, with gross, discount, and net amounts and the delivery and payment status | ## Dates and times All dates are stored as instants in **UTC** (`timestamptz`), using the NodaTime library in the backend, which avoids time zone ambiguities between organizations in different countries. ## Related pages * [Architecture Overview](/en/technical-documentation/documentacao-tecnica/visao-geral.md) * [Scan Flow](/en/technical-documentation/documentacao-tecnica/fluxo-de-scans.md) * [What counts as an artifact?](/en/perguntas-frequentes/licenciamento/o-que-e-contado-como-artefato.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.powermonitor.com.br/en/technical-documentation/documentacao-tecnica/modelo-de-dados.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.