Before You Automate Cornerstone Reporting, Have the Access Conversation

A planning checklist for Cornerstone reporting automation: seven questions to settle the delivery route, access, ownership, file handling, timing, and exceptions before the build starts.

A recurring Cornerstone report can be the starting point for a useful automation. Before we build around it, we need to know how the data can leave Cornerstone, who can authorize that access, and where it needs to go.

Across several client projects, we've used Reporting 2.0 reports delivered by email or placed on the Cornerstone FTP, then processed those files daily. We typically use a system account as the email recipient so that part of the workflow isn't tied to an employee's or contractor's inbox.

The access and delivery details are part of designing the process. These are the questions I'd work through before building it.

1. What does the report need to support?

Start with the task or decision the data will support. A morning completion dashboard, a weekly manager update, and a file used to update user groups can have different requirements.

Agree on the records, fields, filters, destination, and required freshness. If someone needs yesterday's completions each morning, that's a different requirement from needing updates throughout the day.

That gives you something concrete to discuss with the LMS administrator and whoever will build the automation.

2. Which delivery route is available?

For a file-based workflow, establish whether the report can be delivered by email or placed on the Cornerstone FTP. For an API-based workflow, confirm the access available in the organization's portal. Cornerstone's developer documentation describes API access and packaging separately, so it's worth checking exactly what is enabled.[1]

Choose a route that fits the data requirement and the access the organization can provide.

3. Who will set it up and maintain it?

An existing administrator might build the report, or the organization might provide an approved reporting user. Make that responsibility explicit.

Also identify who maintains the report schedule, recipient account, file-transfer connection, or API configuration. A system account still needs an owner who can maintain its access and respond when something changes.

The person building the automation and the person maintaining the Cornerstone report may be different people. Both need to know which changes affect the workflow.

4. How often does it need to run, and in what order?

Write down the required delivery time, time zone, processing window, and downstream refresh order.

For example, a dashboard refresh should follow the arrival and processing of the report it uses. Agree on how the process will confirm that the expected data is ready.

More frequent processing can add work and cost. Match the cadence to the decision or action the data supports, and confirm what the chosen delivery route can accommodate.

5. How will the process recognize the right file?

File names and folders deserve attention at kickoff.

Agree on a stable identifying prefix, expected format, delivery location, and the fields the process needs. Decide how to distinguish a new delivery from an older file or a duplicate.

For email intake, define the permitted senders and expected attachment types. We used those checks in a separate file-intake workflow so an unexpected sender or file type could be identified before loading the data.

If someone renames a report or changes its columns later, the person maintaining the automation needs to know.

6. What happens when the data is large, late, or incomplete?

In one client project without Reporting API or Data Exporter API access, we split a large export into parts by user ID range. In other cases, compressing the file, narrowing the filters, or removing unneeded columns was enough.

Cornerstone's Reporting API and Data Exporter API support paging, which retrieves a result set in batches. The official guidance also recommends validating retrieved data, including checking for duplicate records, before moving it to its final destination.[2]

Whichever route you choose, agree on how you'll check that the expected data arrived. If a delivery has several parts, define how to confirm that all parts are present.

Also decide who receives an alert, what can be retried, and what happens to the previous dataset when the new one cannot be processed. A missing file shouldn't silently become a report showing zero completions.

7. Does any data need to go back into Cornerstone?

Include inbound updates in the scope if the workflow needs them.

For an Edge Import feed, establish who configures the feed, the required file format and mapping, the agreed delivery folder, the necessary FTP access, and who reviews load errors. Depending on the setup, an existing administrator may configure the feed while the automation produces the file.

Exporting a report and importing an update each need their own requirements and owner.

A checklist to take to kickoff

Use this to capture the decisions for one report or feed.

What I like about working through this early is that everyone gets a clearer picture of what they need to provide and maintain.

Start with one recurring report. Identify how it leaves Cornerstone, who owns it, and what should happen when it arrives. That gives the build a clear starting point.

If you'd like help with either side, we offer Automation Services for the build and Cornerstone OnDemand Administration for maintaining the reports, accounts, and feeds behind it.

References

1. Cornerstone API: Getting Access
2. Cornerstone API: Paging