The Spreadsheet Relay Race
Every Monday someone exports Salesforce, pastes it next to a GA4 export, and rebuilds the same pivot table by hand. The report is stale before it is sent.
Salesforce · BI & Reporting
A dashboard is only as trustworthy as the data model underneath it.
Looker Studio — renamed Google Data Studio in April 2026 — is free to use and quick to draw a chart in. The engineering sits underneath: the reporting schema, the blends and the access rules that decide whether the number is right. Twopir Consulting builds that layer on your Salesforce, GA4 and BigQuery data.
12+
500+
40+
250+
Part of the Salesforce delivery work Twopir Consulting has done for 500+ clients — as a Salesforce Partner implementing the agreement and signature layer inside the CRM.
Built For
- Real Estate Brokerages
- Wealth Management Firms
- Legal Operations Teams
- Sales Operations & Deal Desks
- Compliance & Risk Teams
- Financial Services Cloud Users
- Contract Managers
- Professional Services Firms
The tool is free. The friction is not.
Almost every stalled reporting project we are called into has the same shape: the charts render fine, and nobody believes them. These are the five failures we see most.
Dashboards Nobody Trusts
Marketing's numbers do not match Sales' numbers, and Finance has a third version. Three sources of truth means zero sources of truth.
One Report Per Requester
Every exec wants their own view, so someone maintains fourteen near-duplicate report files instead of one governed model everyone filters into.
Blends That Silently Break
A blend works until a field gets renamed upstream, and the dashboard keeps rendering — just with wrong numbers, for weeks, with no error anywhere.
Analysts Doing Connector Work
The person who should be interpreting trends is instead debugging OAuth scopes, connector row limits and refresh schedules.
Sharing By Accident
A report gets shared with a link so a colleague can see it, and now anyone with that link can see every client, region and rep in the underlying source.
Looker Studio, Data Studio and Looker are not the same product
This is the most expensive confusion in the category, and it is worth two minutes before anyone signs anything. One of these three is free. One costs per user. One is an enterprise platform.
Looker Studio · now Data Studio
Looker Studio is Google's free, browser-based reporting tool for building interactive dashboards on top of data you already hold. It connects to Google sources natively — BigQuery, GA4, Google Ads, Google Sheets, Search Console — and reaches everything else, Salesforce and HubSpot included, through partner connectors. In April 2026 Google renamed it back to Data Studio, the name it carried before October 2022. Existing reports, data sources, permissions and shared links carried over; nothing had to be migrated. Both names refer to the same product, which is why both appear on this page.
Looker is a different product and keeps its own name. It is Google Cloud's enterprise BI platform, built around a governed semantic model, and it is priced accordingly. If a vendor quotes you "Looker" for what you asked about as "Looker Studio", that is a materially different licence — check which one is on the order form. Full product detail is on Google Cloud's own product documentation.
Who it is for. Teams that already have their operational data in a CRM and a warehouse, and need one governed reporting layer over the top of it: RevOps and sales operations, marketing analytics, finance and FP&A, customer success operations, agency reporting desks, and the executive group all three of those report into. It is a poor fit as a system of record, as a data-entry surface, or as a substitute for the modelling work described below.
| Product | What it is | Cost shape | When it fits |
|---|---|---|---|
| Data Studio (formerly Looker Studio) | Google's free reporting and dashboard tool. Native Google connectors; partner connectors for everything else. | No licence cost. You pay for engineering, warehousing and any partner connectors. | Most reporting needs, including everything on this page. The default starting point. |
| Data Studio Pro | A paid add-on over the same product: team content ownership, so reports survive the person who built them, plus Google Cloud support. | Per user, per month, on top of the free product. Does not include partner connector fees. | When reports are business-critical and must not be tied to one employee's account. |
| Looker | A separate Google Cloud enterprise BI platform built on a governed semantic modelling layer. Not an upgrade path from the above. | Enterprise platform licence. A different order of magnitude. | Large organisations standardising metric definitions across many teams and tools. |
Verify current pricing and packaging with Google before budgeting
Implement, configure, build on — three different engagements
Twopir Consulting offers all three. They are priced and scoped differently, and most projects that go wrong do so because the buyer thought they were purchasing one and the vendor was delivering another. Here is where each one starts and stops.
Implement
Standing the reporting layer up from nothing: sources connected, data modelled, first governed dashboards live and owned by your team.
- Source inventory and connector selection
- Reporting schema design across Salesforce and Google sources
- BigQuery staging where volume or history demands it
- First dashboard set, built and tested against real edge cases
- Handover, documentation and team training
Configure
You already have Looker Studio. The dashboards exist and are not trusted. This is the tuning engagement, and it is the one we are called into most.
- Rebuilding blends that break on refresh or double-count rows
- Standardising calculated fields so one metric has one definition
- Row-level access rules so one report serves several audiences
- Refresh, caching and extract strategy for slow reports
- Consolidating near-duplicate report files into one filtered model
Build On
Custom development where the product stops. This is engineering work, scoped and estimated separately from the two services above.
- Custom Community Connectors in Apps Script for sources with none
- Salesforce-side Apex and API work to expose reportable data
- Scheduled pipelines into BigQuery for history the CRM will not hold
- Dashboards embedded into Salesforce, a portal or an intranet
- Monitoring and alerting on the models and blends underneath
Where configuration ends and custom development begins
The line is not about difficulty, it is about where the work lives. If the change can be made inside the reporting tool or its data sources — a blend, a calculated field, a filter, a schema change, an access rule — it is configuration, and it is covered by an implement or configure engagement. The moment work requires code that runs outside the report — an Apps Script connector, an Apex class, a scheduled load job, an embed with its own auth — it is custom development, and it gets its own scope, estimate and testing cycle. We tell you which side a request falls on before we quote it, not after.
The work that happens below the chart
Drawing the chart takes an afternoon. Everything below is what makes the number on it correct, current and safe to share. This is the deliverable list, not a feature list.
Salesforce Reporting Schema
Standard Salesforce fields are shaped for CRM screens, not BI queries. We map opportunity, pipeline and custom-object data into a schema built to be reported on.
- Stage, forecast category and close-date normalisation
- Custom object and record-type flattening
- Historical snapshots the CRM does not keep
Multi-Source Blending
Combining Salesforce, GA4, Google Ads and Sheets into one source without the duplicate joins that silently double revenue on the next refresh.
- Join keys and row grain agreed before any chart is drawn
- Fan-out and duplicate-key detection built into the model
- Blend logic documented so the next person can read it
BigQuery Warehousing
When history, volume or cross-source joins outgrow what live connectors handle, we stage the data in BigQuery so the report queries a clean, indexed table.
- Scheduled loads from Salesforce and marketing sources
- Partitioned and clustered tables sized for query cost
- History retained beyond the CRM's own reporting window
Executive Dashboard Design
One governed dashboard with role-based filters, replacing the fourteen near-duplicate files a team builds by hand when everyone asks for their own view.
- One model, many audiences, filtered at the data layer
- Layouts designed for the decision, not the chart library
- Drill paths from the summary number to the record
Metric Standardisation
One definition of pipeline, MRR or SLA breach, enforced across every dashboard, so Marketing and Finance stop arguing about whose number is right.
- A written metric dictionary agreed by the teams involved
- Calculated fields centralised, not copied per report
- Definitions surfaced on the dashboard itself
Row-Level Access Control
Regional managers see their region, reps see their book — one dashboard filtered by identity through Google Workspace permissions, not fourteen copies.
- Access modelled at the data layer, not hidden in a chart filter
- Workspace groups mapped to data-level filters
- Share-link exposure reviewed before anything goes wide
Scheduled Delivery
Email and PDF delivery on a schedule, so the stakeholders who will never open a dashboard still get their numbers on the morning they need them.
- Recipient lists tied to roles, not individuals
- Delivery windows aligned to the reporting calendar
- Filtered variants per audience from the same report
Custom Connector Development
Where a source has no native or partner connector, we build a Community Connector in Apps Script so it refreshes on the same schedule as everything else.
- Auth, schema and pagination handled properly
- Rate limits and quotas respected by design
- Deployed and versioned into your own Google project
Monitoring & Alerting
Watches on the models and blended sources, so a renamed field or a dead connector surfaces as an alert — not as a silently wrong number in next week's board pack.
- Freshness and row-count checks on every scheduled load
- Schema-drift detection on upstream sources
- Alerts routed to a person, not an unread inbox
What actually moves, and in which direction
A logo grid tells you nothing. This is the connection map we actually build, with the business reason for each edge. Reporting is read-only by design: nothing here writes back into a system of record.
| System | Direction | What moves | Why it matters / who consumes it |
|---|---|---|---|
| Salesforce | into reporting | Opportunities, pipeline stages, forecast categories, accounts, activities and custom objects — read through a partner connector, or staged into BigQuery first. | The revenue spine. Sales leadership and RevOps get pipeline and conversion; every other source is joined against this one. |
| Google BigQuery | both ways | Staged copies of CRM and marketing data in, modelled reporting tables out to the dashboard layer. | Where history lives. Finance and analysts get period-over-period comparisons the CRM's own reporting window cannot hold. |
| Google Analytics 4 | into reporting | Sessions, channel groupings, conversion events and landing-page performance, through the native GA4 connector. | The top of the funnel. Marketing sees which channels produce sessions that become Salesforce pipeline, not just sessions. |
| Google Ads | into reporting | Campaign, ad group and keyword spend, impressions and clicks, through the native connector. | Closes the spend loop. Blended against Salesforce revenue, this is what turns cost-per-click into cost-per-closed-won. |
| HubSpot | into reporting | Marketing contacts, email and campaign engagement, and lifecycle stage, through a partner connector or via BigQuery. | For split stacks. Where marketing runs on HubSpot and sales on Salesforce, this is the join that makes one funnel out of two. |
| Google Sheets | into reporting | Targets, quotas, budget plans and mapping tables that legitimately live outside a system of record. | Actual versus plan. Finance owns the sheet, the dashboard reads it — no one retypes targets into a chart. |
| Google Workspace | governs access | Group membership and identity, consumed by the data-level filters rather than by the chart. | Who sees which rows. IT keeps managing access where it already does; reporting inherits it instead of duplicating it. |
| Custom sources | into reporting | Anything with an API and no usable connector, read by a Community Connector we build in Apps Script. | The gap filler. Billing platforms, product telemetry and internal systems land on the same refresh schedule as everything else. |
Salesforce and HubSpot reach this layer through partner connectors or a BigQuery stage — Google does not publish native connectors for either
We do not deploy a tool. We build the reporting layer.
Four phases. Duration depends almost entirely on how many sources are in scope and how clean they are, so we scope it after phase one rather than quoting a number now. Each phase says what we need from you, because that is usually the real constraint.
Data Audit & Source Mapping
We inventory every system feeding your reporting — Salesforce, GA4, Ads, spreadsheets — and document which fields actually agree with each other before we design anything.
We need
Read access to each source, and one person per team who can say what a metric is supposed to mean.
Data Model & Warehouse Design
We build the reporting schema, staging tables and blended sources that sit underneath the dashboard, so the visualisation layer is reading clean, consistent data.
We need
Sign-off on the metric dictionary. This is the phase where definitions get settled, not after go-live.
Dashboard Build & Access Control
We design the governed dashboards, filters and row-level permissions your teams need, then test them against real edge cases before rollout.
We need
A named reviewer per audience, and your Workspace group structure — access is designed in, not bolted on.
Training & Monitoring
We train your team to maintain and extend the dashboards themselves, and set up monitoring so a broken connector gets caught before someone presents wrong numbers.
We need
An internal owner. Every reporting layer that decays does so because nobody inherited it.
Four situations we are called into most
Every one of these starts as a dashboard complaint and turns out to be a data model problem. The fix is almost never in the chart.
Pipeline Trust
Sales leadership stopped trusting the pipeline report six months ago. Twopir rebuilds the Salesforce-to-reporting data model so stage, forecast category and
close-date fields match what is actually in the CRM. The result is one pipeline dashboard
that sales, RevOps and finance all pull from.
Spend vs. Revenue
Marketing can see spend. Marketing cannot see revenue. We blend Google Ads and GA4 spend data against Salesforce-sourced revenue and pipeline,
closing the loop between acquisition cost and closed-won — with the join keys agreed
first, so the blend does not double-count on refresh.
Warehouse Scale
The numbers are right until someone filters by quarter. When native Salesforce or Sheets reporting cannot hold the volume or history finance
needs, we stand up BigQuery as the source and point the dashboards at that instead —
partitioned so the query cost stays predictable.
Client Reporting
One dashboard per client was never going to scale. We build one governed template with row-level access control, so each client sees only
their own data without a separate report file per account — and without a share link
that quietly exposes the rest.
Sales Operations & Lead Management
Rebuilding sales operations and lead management on Salesforce, with the reporting layer that made pipeline velocity and conversion visible to leadership.
Read the Case StudyEvery Twopir Engagement, Written Up
Reporting and dashboard work runs through most of our Salesforce and RevOps engagements. The full library covers the industries, the stacks and the outcomes.
Browse Success StoriesNot a dashboard shop. An architectural partner.
Most reporting problems are data model problems wearing a visualisation costume. We come at this from inside the CRM, which is where the numbers are actually made.
We model the data before we touch the dashboard
The chart is the last thing we build. Schema, grain and join keys come first, because that is what decides whether the number is right.
We have worked inside Salesforce orgs, not just around them
Twopir Consulting is a Salesforce Partner. We know which CRM fields are reliable, which are abandoned, and which quietly changed meaning three admins ago.
We do not charge you for a free tool
The reporting licence is free, and we say so on the pricing call. What you are buying is the modelling, warehousing and governance work — priced as engineering, because it is.
We treat access control as part of the design
Row-level permissions get built in at phase one, not bolted on after someone sees the wrong client's numbers through a shared link.
We build for the team that inherits it
Models are documented and handed over with training. A reporting layer only one vendor can maintain is a liability, not an asset.
Answers before the first call
The reporting tool itself has no licence cost, and that has not changed with the rename to Data Studio. What you pay for is the engineering work to model, blend and warehouse the data feeding it correctly, plus any partner connectors for non-Google sources such as Salesforce, and BigQuery query and storage costs if a warehouse is in scope. The paid tier, Data Studio Pro, is a per-user add-on for team content ownership and Google Cloud support — it does not include connector fees.
Looker Studio and Data Studio are the same product. Google renamed Data Studio to Looker Studio in October 2022, then renamed it back to Data Studio in April 2026. Existing reports, data sources, permissions and shared links carried over both times with no migration required. Looker, without "Studio", is a different product — Google Cloud's enterprise BI platform built on a governed semantic model, licensed at enterprise pricing. If a quote says "Looker" for work you scoped as "Looker Studio", confirm which product is on the order form before signing.
Yes, through a partner connector — Google publishes native connectors for its own sources such as BigQuery, GA4 and Google Ads, but not for Salesforce. Twopir Consulting typically builds a dedicated reporting schema rather than pointing the tool straight at raw CRM objects, because standard Salesforce fields are structured for CRM screens and not for BI queries. On larger orgs we stage Salesforce data into BigQuery first, which removes the connector's row and refresh limits from the critical path entirely.
Many smaller reporting needs work fine on direct connections to Salesforce, Sheets or GA4. A warehouse becomes necessary once you need history the CRM does not retain, volumes that push past connector limits, or joins across sources that live connectors cannot resolve efficiently. We make that call in phase one, after the source audit, rather than assuming a warehouse at proposal stage — it is a real cost and it should be justified by a specific reporting requirement.
If the change can be made inside the reporting tool or its data sources — a blend, a calculated field, a filter, a schema change, an access rule — it is configuration, and it is covered by an implement or configure engagement. The moment the work requires code running outside the report — a Community Connector in Apps Script, Apex on the Salesforce side, a scheduled load job into BigQuery, or an embed with its own authentication — it is custom development, and it gets its own scope, estimate and testing cycle. We tell you which side a request falls on before quoting it.
Twopir Consulting builds row-level access control into the dashboard design itself, using Google Workspace group membership and data-level filters, so one dashboard serves multiple audiences without exposing data they should not see. The important detail is that the filtering happens at the data layer, not in a chart control — a filter applied only to a chart still leaves the underlying rows reachable, which is how share links end up exposing other regions or other clients.
Twopir Consulting sets up monitoring on the data models and blended sources so a renamed field, a schema change or a broken connector surfaces as an alert, not as a silently wrong number in next week's report. This matters more here than in most BI tools, because a blend whose join key disappears will often keep rendering rather than failing. The same monitoring covers migrations: when we move teams off Tableau, Power BI or a legacy setup, we rebuild the underlying data model first, then recreate the dashboards on top of it.
Next Step
If three teams are reconciling the same number every Monday, that is the conversation
Twopir Consulting builds the data models, warehouses and governed dashboards that make Looker Studio reporting something your teams actually trust — on Salesforce, HubSpot, GA4 and BigQuery data, with the access rules designed in from the start.
Speak with a team that models the data before it draws the chart
