How to Create a BI Report in Bitrix24 with BI Constructor

What Is Bitrix24 (Alaio) BI Constructor?

Bitrix24 BI Constructor is a fully embedded analytics layer built on Apache Superset (query engine: Trino) that lets you create live dashboards from your CRM, tasks, telephony, smart processes, and - from ~2026 - external databases, without exporting data to third-party tools.

Unlike Google Looker Studio or a standalone Superset instance, BI Constructor runs inside Bitrix24's own infrastructure. Data stays in your portal; you pay no additional licence fees; and the Superset environment is pre-deployed and ready to use. As of mid-2026, approximately 49,000 companies worldwide use the tool, and ~94,000 custom reports have been created - with 88% of Enterprise-tier clients building their own dashboards.

A key terminology note: "report" and "dashboard" are synonyms in BI Constructor. Inside the Superset interface you work with a dashboard; users opening it from the Bitrix24 menu see it as a report. This article uses both terms interchangeably.

Three report types to know

Type	When to use	Example
Overview	Quick glance at headline KPIs - open, read, close	"Business Key Metrics"
Analytical	Drill down, apply filters, compare segments	"Pipeline Conversion Analysis"
Lens	Narrow, opinionated view on one question	"Product basket analysis", "ABC inventory ranking"

---

Prerequisites: Module, Plan, and First Orientation

Before you can build anything, the biconnector module (~v24.900.0 or higher) must be installed on your Bitrix24 instance; without it, the BI Constructor section will not appear.

For cloud Bitrix24, the module availability depends on your subscription tier - check your plan's analytics section. For self-hosted (on-premise) installations, the module is installed separately; make sure your version meets the minimum requirement.

Practical tip when starting out: set your initial report date range to a single week. Confirm queries run stably before expanding to longer periods or larger datasets. Row limits apply per data source (not globally), so a single oversize query will be blocked with a warning rather than locking the entire BI Constructor.

Once inside, you will see four tabs in the Superset analyst workspace:

• Dashboards - list of existing reports (do not create new reports here directly, or they will be unavailable in Bitrix24)
• Charts - individual visualisations
• Datasets - physical and virtual data sources
• SQL - SQL Lab (query sandbox)

The fastest way to learn the interface is to open any built-in system report, copy it via Menu (≡) → Edit, and explore how its datasets and charts are wired together. System reports serve as live, editable reference examples.

---

Stage 1 - Define the Business Question Before Opening the Tool

Every metric in a BI report must lead to a decision; a metric whose change triggers no action is wasted screen space - design your report around that principle before touching the interface.

The most common mistake when building dashboards is starting with the tool rather than the problem. Bitrix24 accumulates vast amounts of data - deals, leads, contacts, products, calls, tasks - and it is easy to build "pretty charts" that no one acts on.

Use the Dashboard Canvas methodology as a structured design step:

1. Users - who will look at this report, and how often?
2. Questions - what specific questions must the report answer?
3. Metrics - what number, ratio, or trend answers each question?
4. Dimensions / slices - by what fields can users filter or group (date, funnel stage, manager, product category)?
5. Visualisations - what chart type communicates each metric most clearly?

A worked example: a sales manager needs to know which products are most often bought together to recommend bundles. The question is concrete ("top co-purchased product pairs"), the metric is a co-occurrence count, the slice is a date range and sales pipeline, and the right visualisation is a heat map or a ranked table - not a pie chart.

On metrics precision: "conversion rate" has no universal definition. Conversion from what to what must be explicit. Calculating it over all created deals vs. only closed deals gives different numbers for the same period - and both can be correct depending on the question. Define every metric before building it.

---

Stage 2 - Choose or Build Your Dataset

A dataset is the foundation of every chart; Bitrix24 provides ready-made physical datasets for deals, leads, products, tasks, and calls, and you can combine them into virtual datasets using SQL Lab.

Physical vs. virtual datasets

Dataset type	How it works	When to use
Physical (shown with a dark icon)	A real table stored in the database - e.g. crm_deal, crm_lead, crm_deal_product_row	Single-entity reports; quick starts
Virtual (shown with a blue icon)	A saved SQL query that joins one or more tables at query time	Cross-entity analysis; custom fields; basket analysis

All Bitrix24 tables live in the bitrix24 schema on the trino database. When creating a dataset through the UI, select: Database = trino, Schema = bitrix24, Table = the entity you need.

Working in SQL Lab

SQL Lab is the analyst sandbox (SQL → SQL Lab). Write your query, test it on a small date range, then save it as a virtual dataset. Best practices from real projects:

• Aim for one dataset per dashboard, two at most.
• Keep the dataset at row-level granularity (e.g., one row per product-per-deal-per-day). Let Superset handle aggregations on top - don't pre-aggregate in SQL unless necessary.
• Use AS aliases or the Columns tab to give columns human-readable names.
• Add a LIMIT in development queries to avoid large scans during testing.

Available data sources include: CRM deals, leads, contacts, companies, products in deals, tasks, calls, smart processes, inventory documents (~2026: warehouse stock tables such as catalog_store, catalog_store_product, catalog_store_document), and - on Enterprise tier - direct connections to external MySQL and PostgreSQL databases.

---

Stage 3 - Build Charts on Top of the Dataset

Practical dashboards run on 5-7 chart types that any manager reads without training; resist the temptation of exotic visualisations just because Superset offers them.

The chart-building screen asks you to specify:

• Dimensions - categorical fields used for grouping or the X-axis (e.g., product name, manager, month)
• Metrics - aggregated numbers (COUNT, SUM, AVG) that become the Y-axis or cell values
• Filters - row-level conditions applied before aggregation

The practical chart vocabulary

Chart type	Best for
Table	Ranked lists, detailed breakdowns, multi-column comparisons
Line chart	Trends over time
Bar / column chart	Comparing categories
KPI card (Big Number)	Single headline metric
Heat map	Co-occurrence matrices, day/hour patterns
Pie / donut	Simple part-to-whole (use sparingly)
Mixed chart (dual Y-axis)	Volume + rate on the same timeline

Cross-filtering is enabled by default: clicking an element in one chart automatically filters all other charts on the dashboard. You can scope which charts respond to which clicks - useful when some panels should stay static as context anchors.

To speed up chart development, clone an existing chart via Save as new chart and adjust - much faster than building from scratch.

---

Stage 4 - Add Filters and Wire the Dashboard

Filters are control elements that restrict data across all (or selected) charts; each filter is itself backed by a dataset column, and thoughtful filter design determines whether the report is usable or frustrating.

Data flows from Bitrix24 source tables through SQL Lab into a virtual dataset, then fans out into charts and a filter panel that together form the final report.

The flow: CRM tables and custom fields are queried in SQL Lab, saved as a virtual dataset, used to generate multiple chart types, and combined with a filter panel - all assembled into a single dashboard that users open as a report from the Bitrix24 menu.

flowchart LR
    CRM[CRM Tables\ncrm_deal / crm_lead\nproducts / tasks]
    CUSTOM[Custom Fields\n& Smart Processes]
    SQLLIB[SQL Lab\nWrite & Test Query]
    DS[Virtual Dataset\nSaved SQL]
    PHYS[Physical Datasets\nDirect tables]
    CHARTS[Charts\nTables · Lines · Heat maps · KPI cards]
    FILTERS[Filter Panel\nDate · Manager · Funnel · Category]
    DASH[Dashboard = Report\nUsers see this in Bitrix24]

    CRM --> SQLLIB
    CUSTOM --> SQLLIB
    SQLLIB --> DS
    DS --> CHARTS
    PHYS --> CHARTS
    CHARTS --> DASH
    FILTERS --> DASH

Filter types available

• Value / lookup - select from a list (manager, funnel stage, product category)
• Date range - absolute or relative (last 30 days, this quarter)
• Time grain - group by day / week / month
• Organisational structure - filter by department or team hierarchy

Set the scope of each filter explicitly: decide which charts it affects and which should remain unfiltered context panels.

Guard against edge cases: handle division-by-zero in metrics (use NULLIF in SQL), and test what the report shows when a filter returns an empty result set.

---

Stage 5 - Assemble the Dashboard Layout

Layout is the last design step, not the first; place your highest-priority KPI cards at the top-left (where eyes land first), followed by trend charts, then detail tables at the bottom.

Composition principles from real dashboard projects:

• Design from general to specific - overview metrics at the top, drill-down detail below
• Group related charts in visual rows or columns
• Use divider elements and markdown text blocks as section headers
• Keep the number of charts per dashboard reasonable - a report that requires scrolling through 20 panels often means it should be split into two reports
• Apply CSS styling last, after all data logic is confirmed

When multiple pages are needed, use Superset's tab/page feature to keep logically separate views within one report object.

---

Stage 6 - Test, Clean Up, and Publish the Report

Before sharing a report, remove all demo/test data, verify it on a live portal with realistic data volumes, set access permissions, and - if publishing to the Bitrix24 Marketplace - confirm every asset name meets Marketplace naming requirements.

Pre-launch checklist

• All charts load without errors on real (non-demo) data
• Date filters return correct ranges; edge months and quarters tested
• Empty result sets display a clean "no data" message, not an error
• Division-by-zero cases handled in SQL or metric definitions
• Cross-filter scoping reviewed - no unintended chart interactions
• Row limits checked per dataset; no single query risks blocking the session
• Dataset column names are human-readable (via AS aliases or Columns tab)
• Report name, description, and cover image filled in the Report Card ("About this report")
• Access permissions configured (who can view, who can edit)
• If sharing externally: public link generated and tested
• If publishing to Marketplace: all assets (datasets, metrics, calculated fields, charts, dashboard) named per Marketplace rules; demo data removed; partner branding applied

Publishing options

Destination	How
Internal team	Share link or assign access via Bitrix24 permissions
Public URL	Generate a public link from the report settings
Bitrix24 Marketplace	Export archive → submit for moderation (partner branding supported)

---

The Full Pipeline at a Glance

The end-to-end BI report development process in Bitrix24 has five stages; the table below maps each stage to its key action and expected output.

Stage	Key action	Output
1. Design	Define users, questions, metrics, dimensions, chart types	Dashboard Canvas / wireframe sketch
2. Dataset	Select physical tables or write SQL in SQL Lab	Virtual dataset saved in Superset
3. Charts	Configure dimensions, metrics, aggregations per chart	Individual visualisations in the Charts tab
4. Filters	Add filter panel, set scope and cross-filter rules	Interactive filter controls
5. Assemble & Publish	Lay out, test, set permissions, publish	Live report visible to users in Bitrix24

For teams that want to go deeper on the data layer, the SQL and virtual dataset techniques described in Stage 2 integrate naturally with Bitrix24's broader automation capabilities - for example, pulling pipeline conversion metrics that feed into sales funnel automation workflows or referencing the same deal data used by AI call analysis scoring.

If your organisation is evaluating how BI Constructor fits into a broader Bitrix24 rollout, the implementation hours by module reference provides realistic benchmarks for budgeting analytics work alongside CRM and process automation. Teams migrating from platforms like HubSpot or Salesforce will find that CRM migration timeline benchmarks help set expectations for when BI reports can realistically be rebuilt on Bitrix24 data.

For companies where data residency matters - particularly in the EU or UAE - it is worth noting that BI Constructor running on a self-hosted Bitrix24 instance keeps all query results and dashboard data on your own infrastructure, satisfying local data protection requirements without any additional configuration.