Connecting an industry built on disconnected data
Construction runs on data that rarely sits in one place. Information is scattered across platforms, regions, and teams, often locked inside the systems of whichever party generated it. When field data isn't connected to the financial system, that disconnect can hide financial risk. When a project manager, a construction executive thousands of miles away, and a superintendent on the jobsite can't see the same view of a project, decisions get made based on stale or partial information.
Procore, a leading global construction management software provider serving tens of thousands of customers across the U.S., Europe, the Middle East, Asia, and Australia, was built to close those gaps — connecting everyone in construction on a single platform. That means three groups in particular: owners (real estate developers and anyone owning and operating the real estate facility or infrastructure themselves), general contractors who manage projects end to end, and specialty contractors like electricians and plumbers who execute the work in the field.
But connecting data inside Procore is only half the story. Customers also need that data in their own environments, alongside everything else they run the business on (e.g. a general contractor pulling Procore data into Power BI to track workforce and personnel metrics across active jobs, or a customer joining it with their ERP and financial systems to see project execution and cost in one place). That is what Procore Analytics delivers: programmatic access to the connected Procore dataset, pulled into whatever the customer already uses — Power BI, Tableau, Snowflake, BigQuery, their own Databricks workspace, or on-prem SQL Server — for reporting and downstream analysis.
Evolving beyond the first generation of Procore Analytics
The first generation of Procore Analytics predated OpenSharing entirely. It was built on a SQL Server backend. Data was extracted from Procore’s public APIs and loaded into an Azure database that customers could query.
The architecture worked, but it had a hard ceiling. Refreshes were limited to a single daily run, and even customers who paid for additional refreshes were capped at a maximum of three per day. For construction projects where conditions change by the hour, that lag was the single biggest limiting factor.
API-driven extractions also created cost and reliability problems at scale. Pulling data for tens of thousands of customers through public APIs meant running deep recursive calls, which were expensive, brittle, and prone to timing out or hitting limits.
Why OpenSharing
By the time Procore began designing the next generation of Procore Analytics, Databricks was already powering other parts of the Procore platform. That made OpenSharing a natural fit for the customer-facing extract product as well, with several specific advantages over the old API path.
Operational efficiency. Sharing curated files in place removes the cost, brittleness, and timeout risk of running deep recursive API calls for every customer, the same pressure that capped refresh frequency in Procore Analytics 1.0.
Scale. Procore now can share hundreds of curated tables to each customer, maintaining partitioned access per customer to manage hundreds of thousands of distinct data shares at scale. Some of those companies are running hundreds or thousands of concurrent projects, and every one of them needs a current view of the work.
Reach. Procore's customers run on every major cloud and every IT stack imaginable, from Excel and Power BI to fully built-out Databricks environments. OpenSharing's open protocol meets them all. BI tools like Power BI and Tableau work out of the box, and customers who already run on Databricks get a native Databricks-to-Databricks experience without moving any data. Customers on other warehouses and platforms can consume the same shares using the open OpenSharing client libraries.
Reliability and performance. Customers consume curated, governed data that is already cleaned, modeled, and quality-checked, rather than chaining together API calls and stitching the results.
Security and governance. Sharing runs through Unity Catalog, so every table is governed centrally and access is enforced per user and per project. A general contractor can share project progress with the owner while keeping its own financials private.
The implementation 
Procore built Procore Analytics 2.0 on a medallion architecture inside Databricks. Raw events from the Procore application database and integration events land in the bronze layer untouched. Silver applies cleaning, validation, and data quality checks, producing the confirmed datasets that everything downstream depends on. Gold is where the data is aggregated, optimized, and modeled for analytics.
Bronze, silver, and gold all run across multiple regions so processing happens close to the source data. Gold tables are then pulled from each region into a single primary analytics region, which is where OpenSharing fans the data out to customers.
Two recipient paths. Customers without Databricks generate an OpenSharing token directly inside the Procore application and connect using the open protocol. Customers who do have Databricks add their workspace identifier to receive shares natively through Databricks-to-Databricks sharing.
Automated entitlements. A scheduled job watches for new shares and permission changes, reads each user's permissions out of the Procore application, and reconciles the OpenSharing entitlements accordingly. The result is per-user, per-project enforcement with no manual provisioning, so a general contractor can share project progress with the owner while keeping its own financials private, or share trade-partner-scoped data only with that trade partner.
Granularity and incrementality. Procore shares at the schema, view, table, and partition level. Tables have Change Data Feed enabled, so recipients can choose between consuming a full dataset or only what has changed since the last sync, which matters when individual tables hold millions of records.
A common semantic layer. Because the same gold layer powers both Procore's in-app reporting and the customer extract, the schemas and naming conventions line up across products. A customer who sees a value in the Procore UI gets the same value, with the same name, in their extract.
A predictable change cadence. Shipping data to thousands of downstream customer environments means breaking changes have to be telegraphed carefully. A breaking change is anything that can disrupt a customer's downstream pipeline, like renaming a field, changing a column's data type, or restructuring a table. Procore settled on four breaking-change releases per year with six weeks of advance notice, and twelve non-breaking releases per year with three weeks of notice, aligned with the broader organizational release calendar.
A reorganized data team. The old world had two parallel pipelines, one for analytics, one for in-app reporting, each with its own ingestion, modeling, and governance. The new world consolidates that into one path. A single combined pipeline handles ingestion, landing, modeling, and governance, then fans out to data-domain teams aligned to business areas like finance. Each domain team owns its data end to end and works with the relevant application teams on the nuances of each tool, rather than duplicating that knowledge across separate analytics, reporting, and intelligence teams.
Measurable impact
The most tangible business outcome is data availability. While Procore Analytics 1.0 took several years to build out its baseline catalog of available tables and fields with OpenSharing, Procore Analytics 2.0 expanded that catalog to hundreds of tables in less than half the time, effectively doubling the surface area of data customers can extract at scale. That matters because Procore is constantly shipping new capabilities, and every new capability produces data customers want to pull into their own environments. A wider catalog means more of that new functionality is available to customers downstream without one-off integration work.
For end customers, the move to OpenSharing lifted the once-a-day refresh ceiling and reshaped the workday. Customers now schedule refreshes to match the rhythm of their business, and many who pull daily actually pull multiple times per day, on whatever cadence their downstream tools support. A project manager preparing for a major client presentation can take a flurry of last-minute updates from an executive that morning and have the live dashboard reflect them in time for the meeting. In the old model, those nuances had to be explained in the meeting itself.
For internal product teams, a single shared pipeline means a tool team can build a new feature and have its data extractable for customers almost as soon as it ships, instead of waiting months for a parallel analytics pipeline to catch up. Procore expects every gain in tool data availability to translate directly into new product experiences for customers.
A data foundation for reporting, analytics, and AI
Beyond the immediate wins in refresh frequency, scale, and reach, the data architecture Procore built on Databricks and OpenSharing gives customers a governed, continuously available foundation for enterprise-wide reporting and intelligence. Whether a customer is standardizing reporting across every active job, feeding project data into enterprise BI, or building AI on top of it, the value starts the same way: with data that is clean, modeled, governed, and available across every system that needs it.
That is exactly what Procore Analytics 2.0 produces. A single, multi-region gold layer that powers Procore's own application experiences, flows into the products customers build on top of their Procore data, and through OpenSharing and Procore's other data pathways, reaches thousands of construction companies on every major cloud. With that foundation in place, enterprise reporting, analytics, and emerging AI use cases all draw on the same trusted, current source of truth, instead of a series of one-off integrations.
The long-term goal aligns with Procore's mission from day one: to connect everyone in construction on a global platform—giving every team on every project the trusted data they need to build safer, faster, and smarter.
"OpenSharing has helped us increase data availability, which means that everybody in construction, from the executives to the project managers to the folks in the field, has better visibility on the jobs that they do. It's helping them deliver projects on time, on budget, and safely."- Matthew Guptill, Product Manager, Procore Analytics
Building a data product your customers consume in their own tools? OpenSharing gives you one open, governed way to deliver live data across every cloud, region, and platform they run on, with no copies to maintain. See how OpenSharing works, then explore the Databricks Marketplace to share and discover live datasets. Explore OpenSharing
Put your data to work. Procore Analytics turns your project data into actionable business intelligence, connecting information across every job and delivering it to the tools your teams already use. See how Procore Analytics helps you make faster, more certain decisions across your portfolio. Explore Procore Analytics
Instagram Engineering
Shopify Engineering