Exporting Orbit Insights into Power BI, Looker, and Tableau — safely

Quick answer: Pointing Power BI, Looker, or Tableau at your communications data shouldn't require a shared live dashboard link (whose numbers drift per viewer) or a warehouse-native connection to the production database (which reads hot, costs compute, and grants too much access). Devotel Orbit ships CSV exports across Insights → Reports, Insights → Logs, Insights → Analytics, and per-channel message lists, with the cell-level formatting BI tools expect — phone numbers encoded as spreadsheet text literals, timestamps rendered to the operator's IANA timezone, and formula-trigger characters OWASP-prefixed. This post covers what to export, how the exports are shaped for BI loaders, and a safe cadence that keeps your BI model fresh without widening access.

Why a CSV export beats a live connection for BI

Most BI exports fail one of two ways: shared links that drift per viewer, or direct-connect credentials that open more than the report needs.

• A shared live dashboard link renders per viewer, with per-seat filters and date ranges doing whatever they default to. Two people opening the same link can read different numbers, and a Finance partner loading it typically sees the same data under a different timezone.
• A warehouse-native connection (BigQuery, Power BI DirectQuery, Looker's JDBC drivers) opens a live data path into the production database. The BI tool now runs queries against your hot data, and the credentials grant read access wider than the report needs — an ops export should never become a principal in your database.
• A dated CSV export renders once, reads the same for everyone, and terminates access at the file. It is the difference between "give Finance last month's messaging spend" and "give Finance a read connection to the analytics DB."

The export ships data already formatted for BI ingestion — no per-viewer filters leak in, no live data path opens, and the numbers match what the dashboard showed at the moment of export.

What Devotel Orbit ships

Exports live under the Insights tree in the dashboard. The surfaces that matter for BI ingestion:

• [Insights → Reports](https://orbit.devotel.io/en/insights/reports) — the report builder surfaces the canonical analytics outputs (message delivery, channel performance, cost analysis, contact growth, campaign ROI). Each report runs on demand and exports as CSV, with the same columns the card shows on screen.
• [Insights → Logs](https://orbit.devotel.io/en/insights/logs) — the per-message ledger (direction, from, to, status, timestamp, price). This is the row your BI model pivots on.
• [Insights → Analytics](https://orbit.devotel.io/en/insights/analytics) — the aggregate usage metrics (totals, cost breakdown, channel mix) for the period you select.
• Message lists under Messages → (channel) — per-channel exports follow the same column-projection rules below.

Every export goes through a single in-dashboard export path and applies four rules that keep BI loaders from misreading cells. These are the rules your CSV inherits even if you never see them named:

• Phone numbers export as spreadsheet text literals. A leading + (E.164 wire format +38763751511) is a formula trigger in Excel; without protection Excel coerces it to the number 38763751511, and Looker's CSV upload will do the same. The exporter emits identifiers as ="+38763751511" so spreadsheet and BI readers both treat them as strings, and the leading + survives.
• Timestamps are rendered to the operator's IANA timezone. An exported value matches the dashboard wall clock to the second, so a timestamp you read in Power BI matches the one the ops dashboard showed. This closes the "exported time differs from on-screen" defect that otherwise breaks time-based BI filters.
• Formula-trigger characters are OWASP-prefixed. A contact name beginning with =, +, -, @, |, or TAB could otherwise execute as a formula in the receiving spreadsheet. The exporter prefixes such cells with a TAB, neutralising the trigger while preserving the visible text, so opening the CSV in any loader is safe.
• Costs are emitted as plain decimals. A 12.34 USD spend stays machine-parseable (no $ symbol, no thousands separators), so Power BI, Looker, and Tableau parse the column as a number without a currency-format pass.

Which export belongs in the BI model

BI tools ingest CSV cleanly when the file carries the right granularity. Pick per need:

• Message-level rows (Insights → Logs): daily volume, per-recipient spend, deliverability pivots, campaign ROI at the recipient level. The file scales; Power BI and Tableau handle multi-million-row CSVs, and Looker reads it uploaded to BigQuery.
• Report-level aggregates (Insights → Reports → Cost analysis / Channel performance): a Finance-friendly spend-by-channel summary, without shipping the recipient ledger. Useful when the model needs trend lines, not per-recipient detail.
• Aggregate usage metrics (Insights → Analytics): the period overview — totals and cost breakdown — that a board deck opens with.

Don't export "everything" just because the file can carry it; the bigger the extract, the wider the blast radius if the file ends up somewhere it shouldn't. Narrow the export to the columns the model needs.

Wiring the export into Power BI, Looker, or Tableau

Each BI destination ingests CSV with a slightly different prompt, but the file's shape makes the import uniform.

• Power BI: Get Data → Text/CSV → point at the downloaded file. The connection refresh in Power BI Service expects a stable file location, so for recurring imports use Power Automate or a OneDrive/SharePoint folder that syncs the Orbit export on a schedule.
• Looker / Looker Studio: upload the CSV to BigQuery (Looker) or use the File Upload connector (Looker Studio). Because identifiers are emitted as text literals, the upload treats them as strings instead of numbers.
• Tableau: Connect → Text file → point at the CSV. The file's plain-decimal costs parse as numeric without a data-cleaning step.

The common pattern across all three: the export columns stay in the order they shipped, so the import preview matches the dashboard column set, and no per-column type coercion is needed.

Setting a safe cadence without widening access

The scheduled-report surface — Insights → Scheduled reports — emails digests on a fixed cadence; digests are a human-readable summary, not a BI source. For BI ingestion the right cadence is explicit, on-demand exports from the dashboard. That gives you:

• Scope control: the export carries the rows and columns the operator selected this run, so no over-broad service account holds recurring BI-import rights.
• Refresh on demand: pick the date range in Insights → Reports, run the report, and export. The file dates the snapshot, so month-end and quarter-end BI imports stay reproducible.
• Credential isolation: the BI tool never holds Orbit credentials; it reads the file the operator hands it.

If your org needs the same inputs on a recurring schedule, run the export on demand and drop the file into a shared drive or a OneDrive/SharePoint folder your Power BI refresh points at — the BI side stays pull-based, and access terminates at the file.

Three worked examples

• Finance wants monthly messaging spend by channel. Open Insights → Reports, pick Cost analysis, run the date range, export. Power BI reads the cost column as a number without re-formatting, and the export file, not a live service account, becomes the source.
• Ops wants a deliverability trend line. Open Insights → Deliverability or Insights → Reports → Channel performance, export the series you need. Tableau's text-file connector parses the timestamps as strings and the costs as numbers, without a data-cleaning pass.
• CX wants a recipient-level ledger. Open Insights → Logs, set the date range, and export. Each row carries direction, from/to, status, and the message cost; Power BI pivots on the from/to identifiers preserved as text literals, so a pivot by recipient phone number doesn't coerce to a numeric column.

The rule for all three: export the smallest file that answers the question, and keep the export file, not a broad connector, as the access point.

What not to do

Three practices we see and avoid:

• Sharing a live dashboard link to an exec. The per-viewer filters and default date ranges make it meaningless as a data source.
• A warehouse-native connection to production data. It widens access beyond the report and queries against a hot path.
• Assuming Excel's "text" interpretation is safe. Excel strips a leading + from E.164 numbers and reads long digit runs as scientific notation. The exports encode identifiers as text literals so the BI tool reads them as strings on the way in — once Excel has already opened the file wrong, re-importing won't recover the originals.

Point the BI tool at dated CSV exports, and the access stays pull-based and scoped.

Set your first BI feed up

Open Insights → Reports, pick the report that matches the need (Cost analysis for spend, Logs for per-recipient detail, Analytics for the aggregate numbers), and export the CSV. Hand the file to the BI tool with a dated name — monthly reports want this — and register the file location in Power BI Service, Looker's BigQuery importer, or Tableau's shared drive so refreshes pull the newest export. The export file, not the dashboard session, is the interface you maintain.