Most reporting requests start with "I just need one number". The number is usually simple — share of repeat customers, average deal size per segment, how much of the quota a rep has closed — and it appears in none of the ready-made reports. The reports are rarely at fault: there is nothing to count, because the attribute is stored nowhere. Here is what reporting in Bitrix24 (Alaio) actually consists of, and what to do when the built-in tools run out.
What reporting tools does Bitrix24 have?
There are four of them, and they get mixed up constantly.
CRM analytics is the section in the left menu with ready reports: lead overview, first-time and repeat leads, the sales funnel in both conversion and classic views, sales dynamics, period comparison. Its strongest feature is filtering by any field, custom ones included, plus the drill-down: click a bar and you get the deals behind it, not just their count.
The CRM report builder is the older tool with its own templates. It still works, but it is not where the platform is investing, so it is a poor foundation for long-term reporting.
BI Builder covers dashboards in a built-in editor (Apache Superset under the hood) and connections to external analytics such as Power BI and Looker Studio. Data leaves the portal as datasets — deals, leads, tasks, calls, products — and CSV files or external sources can be pulled in alongside them.
Work reports have nothing to do with CRM: they live under Employees, in the time and reports section. On a schedule the portal reminds a person to write up the period; their manager confirms and grades it, and the colour in the list shows whether it was approved with a grade, without one, or not reviewed yet.
When is CRM analytics enough, and when do you need BI?
CRM analytics is enough while the questions sound like "how many deals sit on each stage" and "how did revenue move month over month": pick a filter, pick a period, read the chart. And if the funnel report shows numbers that cannot be true, the data is almost always the culprit rather than the tool — BI will not cure that.
BI Builder earns its keep when data has to be joined: sales against tasks, calls against customer segment, quota against what each rep actually closed. The price is the time on datasets and dashboards, plus somebody who can build them. The middle road is to push raw rows out and count them in the spreadsheet everyone already uses — exporting CRM data covers doing that on an event and on a schedule.
Why is your number in no report at all?
Every builder — CRM analytics, BI Builder, an external dashboard — can only aggregate what sits in fields. It has no idea a customer is a repeat one unless the card says so, cannot measure time on a stage nobody recorded, and will not show quota attainment until the quota is a field. Hence the working rule: field first, report second. The metric is calculated by automation at the moment of the event, and the report only displays what was already computed — which is why the same number then matches in the dashboard, in the card, and in the export.
How to calculate a custom metric with automation
The pattern is always the same: a rule computes the value, the value lands in a field, the field shows up in filters and datasets. Percentages and shares come from Percent of number — quota attainment, margin, share paid upfront. Totals and counts across multiple values or related records come from Sum of array, while Ternary (if-then-else) stamps a large-deal or ordinary label against your threshold, so the report splits into segments with no manual tagging. Update deal by ID writes the result into a custom field, which from then on behaves exactly like a stock one. The arithmetic itself is assembled from the blocks described in calculations inside workflows, and the wider picture of what runs when lives in the workflow automation guide.
Some metrics are better kept in the card than recomputed by a process: the Customer LTV field adds up the amount and number of purchases across a contact's whole history, Formula field evaluates an expression over neighbouring fields as the card opens, and Progress bar draws attainment as a bar. Back-fill for earlier periods is a job for bulk workflow launch: one template that computes and writes, fired across the whole base, so the report has history and not just today.
How to send the numbers to an external system
When the analytics lives outside the portal, nobody has to wait for a manual export: the HTTP request robot posts computed values to your warehouse, spreadsheet, or BI tool the moment a deal closes, a stage changes, or a payment lands. That stream pairs well with datasets: heavy slices come from BI Builder on a schedule, operational events arrive as they happen.
What next
Do not start with a dashboard. Start with the question: which number do you want to see every week? Give it a field, add a rule that fills the field at the moment of the event, back-fill with a bulk launch — and only then build the report. The calculation blocks live in the robot catalog, the metric fields in the field catalog. If the block you need is missing, describe the task: we build missing activities for free and ship them to the shared library.