Cornerstone to Power BI: Reporting 2.0 vs Reporting API vs Data Exporter API

Compare Cornerstone Reporting 2.0, Reporting API, and Data Exporter API for Power BI. Learn which approach fits your reporting needs, data volume, refresh requirements, and long-term architecture.

The answer could be Reporting 2.0, the Reporting API, the Data Exporter API, or a combination of them.

The important part is understanding that these are not simply three different ways to retrieve the exact same dataset.

They solve different reporting problems.

For a relatively straightforward compliance dashboard that refreshes daily, building a reliable Reporting 2.0 report and automating the output may be enough.

For an enterprise learning data model that combines Cornerstone with HR, operational, security, finance, or other business data, an API-based pipeline is usually a more appropriate architecture.

And if you are building that pipeline today, there is an important distinction between Cornerstone's older Reporting API and its newer Data Exporter API.

First: Reporting 2.0, Reporting API, and Data Exporter Are Closer Than They Look

Cornerstone's reporting architecture starts with its Real-time Data Warehouse, or RTDW.

According to Cornerstone's developer documentation, the RTDW is refreshed from the transactional database at approximately 15-minute intervals and serves:

• Reporting 2.0
• Custom reporting
• Reporting API
• Data Exporter

That means moving from Reporting 2.0 to an API does not automatically mean you are moving from "old data" to "real-time data."

All three reporting approaches ultimately depend on the RTDW.

The bigger differences are:

• How the data is exposed
• How much transformation is already done for you
• How efficiently large datasets can be retrieved
• How historical data will be maintained
• How multiple datasets are combined
• How much technical infrastructure your team wants to own

That is why the decision should start with the reporting requirement, not with Power BI.

We discussed the same principle in Before You Build Another Dashboard, Make Sure Cornerstone Is Report-Ready: defining the business question and validating the underlying LMS data should happen before choosing the visualization layer.

Power BI does not fix an unclear Cornerstone data model.

Option 1: Reporting 2.0 to Power BI

Reporting 2.0 is usually the lowest-complexity starting point.

An administrator builds the dataset inside Cornerstone, applies the appropriate fields and filters, and exports or schedules the resulting file. That file can then feed another reporting process.

A simplified architecture might look like:

Cornerstone Reporting 2.0
        ↓
Scheduled Excel/CSV output
        ↓
File storage / automation
        ↓
Power BI

This can work very well when the reporting requirement is clearly defined.

Reporting 2.0 makes sense when:

• The dataset can be created cleanly in Reporting 2.0
• Refreshing daily or on another scheduled cadence is acceptable
• Only a small number of reports need to feed Power BI
• The data does not require complicated joins across many Cornerstone objects
• The organization wants to minimize custom development
• The dashboard primarily reports on Cornerstone data
• An LMS administrator needs to be able to understand and maintain the source report

There is nothing inherently wrong with using scheduled report files as a data source.

The problem starts when the entire reporting operation becomes dependent on manual exports, spreadsheet cleanup, file replacement, and undocumented transformations.

We covered one way to automate that workflow in Stop Manually Exporting LMS Reports: Automate Google Sheets Updates in Minutes.

The same principle applies to Power BI: if Reporting 2.0 provides the correct dataset, automate the movement of that dataset instead of having an administrator manually download and replace it.

Where Reporting 2.0 starts to struggle

Reporting 2.0 becomes less attractive as requirements expand.

For example:

• Power BI needs several large Cornerstone datasets
• Reports require significant transformation after export
• Historical snapshots need to be retained
• Multiple business systems need to be joined together
• Refresh requirements become more frequent
• Different dashboards repeatedly require the same underlying Cornerstone data
• File-based processes are becoming difficult to govern
• Reporting 2.0 scheduling becomes part of the bottleneck

At that point, the organization is no longer solving a report problem.

It is building a learning data pipeline.

We have also covered Reporting 2.0 scheduling specifically in How to Work Around Cornerstone Reporting 2.0's Scheduling Limits. Workarounds can be useful, but they should not substitute for an API architecture when the reporting requirement has clearly outgrown scheduled reports.

Option 2: Cornerstone Reporting API to Power BI

Cornerstone's Reporting API, commonly referred to as RAPI, provides programmatic read-only access to the RTDW using OData.

The Reporting API exposes the familiar vw_rpt_* reporting views.

These views are generally denormalized. In practical terms, Cornerstone has already done a significant amount of the work required to combine underlying relational data into reporting-oriented datasets.

That can make some Reporting API views convenient for analytics.

A typical architecture might look like:

Cornerstone Reporting API
        ↓
Data extraction process
        ↓
Staging / database
        ↓
Transformation and data model
        ↓
Power BI

Reporting API can make sense when:

• An existing integration already depends on vw_rpt_* views
• The required business data is not yet available through a Data Exporter core object
• A particular Reporting API view already provides the dataset needed
• Rebuilding a stable existing pipeline would provide little benefit
• The denormalized structure materially simplifies a specific reporting requirement

The Reporting API is still a valid tool.

But for new development, it should no longer automatically be the default.

Why Cornerstone Is Moving Toward Data Exporter API

Cornerstone describes the Data Exporter API, or DEAPI, as the successor to the Reporting API architecture.

The difference is significant.

Reporting API views attempt to provide relatively wide, denormalized reporting datasets.

Data Exporter API exposes streamlined core objects that are normalized and designed to be transferred efficiently and combined downstream.

Cornerstone's own guidance is clear:

When the same business item is available through both Reporting API and Data Exporter API, customers should give strong consideration to Data Exporter API.

Cornerstone also states that equivalent Reporting API endpoints may be deprecated over time as Data Exporter coverage expands.

That makes DEAPI especially important when designing a new Cornerstone-to-Power-BI architecture.

Option 3: Data Exporter API to Power BI

Data Exporter API changes where some of the reporting work happens.

Instead of Cornerstone returning a heavily denormalized reporting view, DEAPI exposes normalized core objects that your organization can retrieve, store, relate, and transform.

A more scalable architecture therefore looks like:

Cornerstone Data Exporter API
        ↓
Raw / staging tables
        ↓
Learning data model
        ↓
Business logic and transformations
        ↓
Power BI

If other systems are involved:

Cornerstone DEAPI ─────┐
HRIS ──────────────────┤
ERP ───────────────────┤
Security / Operations ─┤
Other business data ───┘
            ↓
      Data warehouse
            ↓
   Learning data model
            ↓
         Power BI

This is where Power BI reporting can move beyond LMS reporting.

Instead of asking only:

How many people completed this course?

the organization can potentially answer questions that require Cornerstone data to be combined with data outside the LMS.

That is a materially different use case.

Why DEAPI Is Better Suited to a Data Pipeline

Several characteristics of Data Exporter API matter when building a durable reporting architecture.

1. Core objects have unique keys

Cornerstone documents that DEAPI core objects are always keyed.

That matters when data is being stored locally because a reliable key gives the receiving system a consistent way to identify records and perform merge or upsert operations.

Reporting API views may or may not have an equivalent unique key.

2. DEAPI supports change-oriented extraction

One of the biggest mistakes in LMS reporting architecture is repeatedly pulling an entire historical dataset when only a small percentage of the data has changed.

Data Exporter is specifically designed to avoid that pattern.

Cornerstone recommends establishing an initial local baseline and then retrieving changes after that baseline has been created.

Depending on the object, DEAPI provides mechanisms including:

• _last_touched_dt_utc
• OData change tracking

With supported OData change tracking, the process can identify inserted, updated, and deleted records.

That creates a much better foundation for maintaining a local Cornerstone dataset than repeatedly reprocessing the full history.

3. DEAPI provides extended metadata

Data Exporter exposes metadata describing the available core objects and their capabilities.

That includes information such as:

• Unique keys
• Field definitions
• Data types
• Nullable fields
• Available indexes
• Filterable fields
• Object relationships
• Change-tracking capabilities

This becomes important when building production-grade integrations.

For example, not every DEAPI field can simply be placed into an OData $filter. Cornerstone exposes index information through the metadata so the integration can determine which fields support filtering.

That is the type of detail that becomes important once a Power BI project moves beyond a proof of concept.

4. DEAPI is designed for downstream relationships and transformation

Normalized objects mean you will often need data from several objects.

Cornerstone does not allow DEAPI or RAPI to perform joins between reporting objects in a single API query.

For multi-object reporting, Cornerstone recommends an ELT approach where the required objects are retrieved into a local database and joined there.

That is an important architectural point.

If your Power BI model needs users, organizational units, transcripts, training metadata, curricula, custom fields, and other related data, repeatedly calling APIs from inside report logic is usually not the right design.

Retrieve the necessary Cornerstone objects.

Store them.

Model the relationships.

Then let Power BI consume a reporting model built for the business question.

Reporting 2.0 vs Reporting API vs Data Exporter API

| Consideration | Reporting 2.0 | Reporting API | Data Exporter API | | ------------------------------------------------------- | -------------------------------------------- | ----------------------------------------------------- | ----------------------------------------------------- | | Primary use | In-platform reporting and scheduled datasets | Programmatic reporting through legacy reporting views | Scalable extraction into downstream data systems | | Source | RTDW | RTDW | RTDW | | Interface | Cornerstone report builder | OData API | OData API | | Data structure | Report-defined output | Often denormalized vw_rpt_* views | Normalized core objects | | Technical effort | Low | Medium to high | High | | Local data model required | Usually no | Often | Usually for advanced reporting | | Unique keys | Depends on report | Not always | Yes | | Extended metadata | Not applicable | Limited compared with DEAPI | Yes | | Change tracking | No API-style delta process | No OData delta | Supported for applicable objects | | Best fit for new enterprise pipeline | Sometimes | Depends on coverage and existing architecture | Usually preferred when required objects are available | | Good fit for simple daily Power BI feed | Yes | Possibly | Possibly, but may be unnecessary complexity | | Good fit for combining Cornerstone with enterprise data | Limited | Good | Strong |

Does This Mean Every Power BI Project Should Use Data Exporter?

No.

This is where architecture decisions often become unnecessarily complicated.

If an L&D team needs one reliable Power BI dashboard and Reporting 2.0 already produces exactly the required dataset, standing up an API integration, staging database, transformation layer, and monitoring process may create more infrastructure than the problem requires.

On the other hand, if five Reporting 2.0 files are being merged every morning, Power Query contains pages of cleanup logic, historical files are being retained manually, and leadership now wants HRIS or operational data added to the dashboard, the file-based model may already have outgrown itself.

The goal should be to use the simplest architecture that will remain reliable at the expected scale.

Not the most technical architecture.

A Common Mistake: Connecting Power BI Before Designing the Data Model

The question is often phrased as:

How do we connect Cornerstone to Power BI?

A better question is:

What Cornerstone data do we need, how should that data be modeled, how frequently does it need to change, and what other business data needs to be combined with it?

The Power BI connection comes after those decisions.

Before building the pipeline, define:

1. The business questions. What decisions should the dashboard support?

2. The Cornerstone objects required. Do you need transcripts, training, curricula, users, organizational data, certifications, custom fields, or something else?

3. The required history. Do you need the current state, historical transactions, periodic snapshots, or all three?

4. The refresh requirement. Is daily sufficient? Does the business actually need intraday updates?

5. The transformation logic. Which definitions need to be standardized before reaching Power BI?

6. Other systems involved. Will Cornerstone data eventually be combined with HRIS, ERP, operational, security, financial, or other business data?

7. Ownership. Who will maintain the extraction process, data model, credentials, transformations, and Power BI dataset when Cornerstone changes?

These questions usually make the appropriate technical path much clearer.

Data Quality Still Comes First

Moving to an API does not automatically improve the data.

If training metadata is inconsistent, curriculum structures are unclear, organizational data is unreliable, or assignment logic creates unexpected transcript records, the API will simply deliver those problems more efficiently.

This is why we recommend validating reporting readiness before investing heavily in dashboard architecture.

Our article Before You Build Another Dashboard, Make Sure Cornerstone Is Report-Ready covers the operational side in more detail, including curriculum structure, assignment logic, permissions, and data quality.

The technical pipeline and the LMS configuration have to work together.

One More Consideration: Reporting Data Is Not Transactional Real-Time Data

Cornerstone documents that its reporting APIs operate against the RTDW rather than directly against the transactional database.

The RTDW is refreshed from the transactional system at approximately 15-minute intervals.

That distinction matters when stakeholders use words like "live" or "real time."

For most learning analytics, a short reporting delay is irrelevant.

For a workflow that must react immediately to a learner action, reporting infrastructure may not be the appropriate integration mechanism at all.

Reporting architecture should be designed around reporting requirements, not transactional workflow requirements.

What We Typically Recommend

There is no universal answer, but the decision usually falls into three patterns.

Use Reporting 2.0 when:

The report can be built cleanly inside Cornerstone, file delivery is acceptable, refresh requirements are modest, and the organization does not need a broader learning data platform.

Keep or use Reporting API when:

A required dataset is available through an existing vw_rpt_* view, particularly when an established integration already depends on that view or DEAPI does not yet cover the required business object.

Favor Data Exporter API when:

You are building a new scalable data pipeline, the required core objects are available, you need incremental data movement, or Cornerstone will become one source within a broader enterprise reporting architecture.

For many organizations, the final architecture is not purely one of these.

Reporting 2.0 may continue handling operational reports while DEAPI feeds a centralized data model used for executive Power BI reporting.

That can be completely appropriate.

The objective is not to eliminate Reporting 2.0.

It is to stop asking one reporting tool to solve every reporting problem.

Before Choosing, Answer These Questions

If your L&D team is deciding how to connect Cornerstone to Power BI, these are the questions we would start with:

• What Power BI dashboards are you actually trying to build?
• Which Cornerstone data domains are required?
• How large are the datasets?
• How much history needs to be retained?
• How often does the data genuinely need to refresh?
• Are you currently cleaning or combining Reporting 2.0 exports manually?
• Does the dashboard need data outside Cornerstone?
• Do the required DEAPI core objects currently exist?
• Are there existing Reporting API integrations that should remain in place?
• Where will raw and transformed data live?
• Who owns the pipeline after implementation?
• How will changes to Cornerstone fields or reporting objects be tested before reaching production?

If those answers are unclear, choosing an API is premature.

Define the reporting architecture first.

Then choose the smallest Cornerstone extraction method that supports it.

Where Lernevate Fits

Lernevate works with learning teams at the point where Cornerstone reporting stops being just a report-building exercise and becomes a data architecture problem.

That can include:

• Evaluating Reporting 2.0 versus API-based reporting
• Designing Cornerstone-to-Power-BI data pipelines
• Mapping Reporting API views and Data Exporter core objects
• Building repeatable extraction and transformation processes
• Combining LMS data with HR and business data
• Designing Power BI reporting models
• Troubleshooting data discrepancies between Cornerstone and downstream reports
• Reducing manual report preparation
• Making Cornerstone itself more report-ready before the dashboard is built

If your team is currently deciding between Reporting 2.0, Reporting API, and Data Exporter API, that is usually worth discussing before development starts.

A short architecture review can prevent a simple reporting requirement from becoming an unnecessarily complicated data platform, or prevent an enterprise reporting requirement from being forced into a collection of scheduled spreadsheets.

Frequently Asked Questions

Can Cornerstone connect to Power BI?

Yes. Cornerstone data can be supplied to Power BI through several architectures, including scheduled Reporting 2.0 outputs or API-based extraction using Reporting API or Data Exporter API. The right approach depends on data volume, refresh requirements, transformation needs, historical requirements, and whether Cornerstone data must be combined with other systems.

Is Cornerstone Data Exporter API replacing Reporting API?

Cornerstone describes Data Exporter API as the successor to Reporting API and recommends giving strong consideration to DEAPI when the same business item is available through both. Cornerstone also indicates that Reporting API endpoints may eventually be deprecated when equivalent data is available through DEAPI.

That does not mean every Reporting API integration should immediately be rebuilt. Existing coverage, dependencies, business value, and migration effort should be evaluated first.

Is Data Exporter API real time?

Data Exporter API reads from Cornerstone's Real-time Data Warehouse. Cornerstone documents that production RTDW data can lag the transactional database by up to approximately 15 minutes.

Should Power BI connect directly to Cornerstone Data Exporter API?

For a small use case, direct retrieval may be technically possible. For broader reporting that requires multiple Cornerstone objects, Cornerstone recommends retrieving those objects into a local data store and joining them there.

That architecture also provides a better place to manage history, transformations, relationships, validation, and data from systems outside Cornerstone.

Should we use Reporting 2.0 or Data Exporter API for Power BI?

Use Reporting 2.0 when it already provides a maintainable dataset at the cadence the business needs.

Consider Data Exporter API when the reporting requirement needs scalable extraction, incremental updates, multiple related Cornerstone objects, historical persistence, or integration with a larger enterprise data model.

Does moving to the API solve Cornerstone reporting accuracy problems?

Not necessarily.

Reporting 2.0, Reporting API, and Data Exporter all depend on Cornerstone reporting data. Problems caused by LMS configuration, inconsistent metadata, curriculum design, assignment logic, or unclear reporting definitions still need to be resolved upstream.

That is why the architecture conversation should include both the data pipeline and the Cornerstone configuration behind it.