Integration · 2024

Quick Facts

• Industry: Retail
• Platform: OneStream + PDI (general ledger)
• Impact: A live SIC connection to PDI replaced scheduled file movement, and OneStream became the source of truth for per-store attributes — held as entity text properties backed by an audited table that a CSV upload keeps current.

---

Overview

A retail business running a large fleet of convenience stores keeps a pile of per-store attributes — the descriptive properties that hang off each store. Those attributes lived in an older external system, and the store's general ledger lived in PDI, separate from OneStream. Two pieces of work brought it together. First, a live SIC connection between OneStream and PDI so trial balance, store attributes, and anything else could be pulled on demand rather than moved on a schedule. Second, OneStream became the authoritative home for the attributes themselves: they're held as entity text properties, but the real source of truth is an audited backing table that a simple CSV upload keeps current — so the old attribute system could be retired.

The Problem

• Store attributes lived in a separate, older system. Every per-store attribute was maintained outside OneStream, which meant the finance platform was always working from a copy rather than the original.
• Entity text properties drift if you let them. The natural place to put these attributes in OneStream is entity text properties — but those are editable on the entity, so nothing stops someone changing one by hand and quietly diverging from the agreed values.
• PDI data arrived on a schedule. The general ledger lived in PDI on the client side; getting trial balance and store data into OneStream meant scheduled file movement rather than a live read.

Process

Make the attribute table the source of truth — not the entity

The attributes are surfaced in OneStream as entity text properties so they're usable everywhere the platform already reads them. But because text properties are hand-editable, the authoritative copy is a backing table with a full audit trail — who changed what, when, and to what. On each refresh the entity text properties are re-applied from the table, so if anyone edits an attribute directly on an entity, the next cycle simply restores the table's value. The table always wins. Drift can't accumulate.

Let the business maintain attributes with a CSV

Updating attributes had to be something the client could do themselves. They drop a CSV of attributes and OneStream picks it up automatically: an extender rule ingests the file, applies every attribute change across the matching members, and writes the audit-trail history as it goes. A bulk re-tag that used to mean editing members one at a time becomes one upload.

Wire OneStream to PDI over SIC

PDI is the client's general ledger. We stood up a SIC connection between OneStream and PDI so OneStream could pull what it needed — trial balance, store attributes, whatever the workflow asked for — directly and on demand, replacing the scheduled file movement that the integration had relied on.

Solution

1. Audited attribute table behind entity text properties

Per-store attributes live as entity text properties for usability, but the source of truth is a backing table with full audit-trail history. Text properties are re-applied from the table every refresh, so manual edits can't cause drift.

2. CSV-driven attribute updates

A dashboard CSV upload, ingested by an extender rule, applies bulk attribute changes across the matching members and records who-changed-what history automatically — replacing the old external attribute system.

3. Live SIC connection to PDI

A SIC connection between OneStream and PDI lets load rules pull trial balance, store attributes, and other GL data on demand instead of waiting on scheduled files.

Results

Soft outcomes:

• One place owns the attributes. OneStream stopped being a downstream copy of an external system and became the place the attributes actually live.
• Manual edits stopped mattering. Because the table re-asserts itself every refresh, a stray hand-edit is a non-event rather than a reconciliation problem.

Learnings

What worked. Treating entity text properties as a projection of the table rather than the store itself. Text properties are the right surface for usability but the wrong place for the source of truth, because they're editable; backing them with an audited table and re-applying on every refresh gives you both the convenience and the guarantee.

What I'd do differently. Nothing structural — but the CSV-and-extender pattern for bulk attribute maintenance is reusable enough that it should have been the first thing built, since it's what made the client self-sufficient.

Skill developed. Designing master-data ownership inside OneStream without bolting on external middleware: a table for truth, text properties for reach, a CSV path for maintenance, and a live SIC link for everything that still lives in the GL.