Rippling Data Cloud: Object History

As part of today’s Rippling Data Cloud announcement, we enhanced the object history capability across Rippling, which makes AI-powered analysis of business data faster and more accurate. Some business questions are impossible to answer correctly from current-state data. Object History makes those questions answerable.

What is Object History?

Object History is the ability to query the value of an object at any point in time, as well as when a given change occurred, who made it, who approved it, and why. When combined with Rippling Audit Logs and Rippling Workflow execution history, it provides a complete picture of how data has changed over time.

Today, Rippling Object History supports changes made to the Employee record, including custom fields. When combined with Data Connectors and Transformations, this allows analysts to evaluate connected business data, like sales, support, or engineering data, on the dimension of how the people associated with that data have changed through time.

What Object History enables

The most important business questions require an analysis of data over time. Although point-in-time analysis can be useful (“how much revenue was booked yesterday”), more valuable questions require accurate historical data across a set of fields (“show the bookings performance of each sales team over the past four quarters”). The latter requires the historical team membership for each salesperson who was active during the period.

These types of business questions abound:

• How long after first becoming an account executive did each rep close their first deal?

• Which managers are best at keeping support volume low, accounting for all the org shifts that have happened over time?

• Which managers in my org have the highest attrition rate?

• Which job sites have trended best and worst for late clock-ins so far this year?

• What are the average PRs per engineer over the past eight quarters, grouped by job level?

• Which employees were members of this team when we received the most customer complaints?

• How did headcount change by department, location, or manager over the last year?

• Which employees were included in this payroll run, and what department, location, or manager context applied at the time?

Without Object History, BI systems can return wildly inaccurate answers to these kinds of questions. The solution has been to pay a data scientist to model history data for a given query or report using manual snapshots of the data that attempt to mimic this capability. With Rippling, you get a bulletproof version of this capability out of the box, without rebuilding history models for every analysis.

History everywhere

Rippling treats each supported field as a time series, and saves metadata every time a field’s value changes. It then exposes history through functions that can be used where users actually put their data to work: reports, dashboards, transformations, AI answers, workflows, and custom apps.

The power is in the simplicity:

• VALUEASOF(field, date) returns the value of a field as it existed on a specific date.

• DATEOFCHANGE(field, "FIRST" | "LAST" | n, optional_filter) returns the date of a given change.

That makes history available in the same analytical layer where people build metrics. You do not need a special report type, a separate API call, or a hand-built history table for every analysis.

Critically, access is governed by the same permissions model that protects the underlying data. Historical analysis will not become a backdoor to sensitive data, such as employee compensation.

When history is exported from your business systems for processing, it quickly becomes fragmented. One team keeps Salesforce snapshots in a warehouse. Another exports org changes to CSV. A data scientist builds a custom, slowly-changing dimension for one dashboard. Each version may answer one question, but none becomes a governed, reusable understanding of what the business looked like over time. AI is then left to guess which version of history to trust, how it relates to current data, and whether the user is allowed to see it. Rippling makes history part of the platform instead, so people and AI can reason from the same permissioned record of what changed, when it changed, and what the business looked like at the time.

A different approach to the problem

When a manager is reorganized under a new VP, all employees under that manager get a new skip-level manager. But nothing in the records of the individual employees changes; only the reporting line of their manager. So when the time comes to ask the question, “who reported to whom before that change happened,” the answer isn’t an easy thing to compute.

Rippling solves this by centralizing history at the platform layer. Changes to supported employee fields and org relationships are captured with effective dates, then turned into queryable historical state. For hierarchy fields like manager, department, and team, Rippling can maintain point-in-time hierarchy paths, so reports and AI do not have to rebuild old org trees from raw change logs every time someone asks a historical question.

Where this changes the analysis

One very simple example of this issue is in evaluating the performance of newly-hired sales reps, something every sales team measures continuously. How would you calculate time to productivity?

We can define time to productivity as follows: time_to_productivity = DATEDIFF(first_closed_won_date, rep_start_date)

The formula looks simple, but many reps started out as sales development reps, and later became account executives. In that case, hire date is the wrong starting point. The right question is how long it took to close the first qualifying deal after becoming an AE. DATEOFCHANGE(job_title) gives you the role-change anchor. From there, a transformation can find the first qualifying opportunity after that date, attribute it to the correct manager at the time, and compute the ramp period.

Why this matters for AI context

AI is only useful if it can answer the question you actually asked. When a user asks “who was on this team when attrition spiked?” an AI layer on top of current-state data will answer quickly and confidently, but incorrectly. When a user asks “why did this metric suddenly change?”, an AI layer that cannot see business events, workflow activity, and audit logs can only guess.

Rippling AI can use the same history-aware functions, business events, and audit-log context available in Data Cloud. It can understand not just the row, but the context around the row: whom the employee reported to at the time, which department they belonged to, what workflow fired, what changed, who changed it, and what permissions apply. The answer is traceable to actual historical state and operational events, not inferred from today’s org chart or reconstructed from table names alone.

Data history should not be a research project

If reconstructing the facts from six months ago requires exports, old org announcements from Slack, workflow screenshots, audit-log exports, ETL logs, and a few colleagues with institutional memory, the analysis will either be skipped or quietly approximated. Rippling Data Cloud makes history part of the platform: point-in-time where the object supports it, change-aware where workflows need to react, event-native where the business record already represents what happened, and audit-aware where the question is who changed what and when. And it is available to reports, transformations, dashboards, AI, and workflows through the same system.

It improves the trustworthiness of any analysis you do with your business data.