Integration · 2024

Quick Facts

• Industry: Consumer brands (multi-brand group)
• Platform: OneStream (Extensibility rules) + Google Drive
• Impact: When a direct NetSuite-to-OneStream connection wasn't possible, a connector-free Extensibility-rule path through Google Drive got the data in anyway — unattended, on demand, or scheduled, with each brand's load running in parallel and a manual upload falling out of the same path for free.

---

Overview

The client couldn't give us what a normal integration needs: a SQL query to build a direct NetSuite-to-OneStream connection. They were a Google-heavy group, so rather than force a direct connection that wasn't on offer, I used Google Drive as a middle layer. A OneStream Extensibility rule reaches into a Drive folder, pulls the latest file, converts it to a byte array, and feeds OneStream's Import / Validate / Load API directly — so there's no connector, no upload prompt, and nothing to babysit. The group spans several brands, so the rule runs each brand's load in parallel to get the whole set in faster. And because the path is connector-free and file-based, the same rule doubles as a manual upload and a drop-it-on-Drive on-demand or scheduled trigger.

The Problem

• No SQL query for a direct connection. A OneStream connector works off a SQL query or a REST API — and the client couldn't expose one for NetSuite. The obvious direct path was simply closed.
• A normal import step prompts for a file. If you wire this as a standard Import / Validate / Load step, OneStream prompts the user to pick a file — so it can't run unattended, on demand, or on a schedule.
• The data spanned several brands. Loading each brand's file one after another would make the slowest brand gate the whole cycle.

Process

Route the data through Google Drive

With a direct connection off the table and the client already living in Google, Google Drive became the exchange surface. Files land in a Drive folder; OneStream reads from there. Drive is the middle layer that stands in for the connection the client couldn't provide.

Use an Extensibility rule instead of a connector

A connector expects a SQL query or REST API, not a file — and a normal import step prompts for an upload. So I used an Extensibility rule, which runs inside OneStream without prompting. The rule reaches into the Drive folder, pulls the latest file, converts it to a byte array, and passes that byte array to OneStream's Import / Validate / Load Import API. The API loads the bytes to stage; validate and load to the cube step then run through the APIs as well. The whole sequence runs unattended — no connector, no prompt, no manual click.

Run the brands in parallel

The group is several brands, each with its own file. Rather than process them sequentially, the rule runs the brands' loads in parallel, so the overall load finishes in the time of the slowest brand rather than the sum of all of them.

Get the manual and scheduled paths for free

Because the path is connector-free and file-based, it isn't a single rigid pipeline. The same rule supports a manual upload, and an on-demand or scheduled load — drop the file on Drive and the rule picks it up. There's no separate workflow for manual loads; it's all one path.

Solution

1. Google Drive middle layer

Stands in for the direct NetSuite connection the client couldn't provide. Files land in a Drive folder; OneStream reads from it.

2. Extensibility-rule ingest

A rule that pulls the latest file from Drive, converts it to a byte array, and drives OneStream's Import / Validate / Load API directly — load to stage, then validate and load to the cube step, all through the APIs, with no connector and no upload prompt.

3. Parallel brand loads

Each brand's file loads in parallel rather than sequentially, so the slowest brand sets the pace instead of the total.

4. Connector-free manual + scheduled fallback

The same connector-free path serves manual uploads and on-demand or scheduled loads — drop a file on Drive — with no separate manual-load workflow.

Results

Soft outcomes:

• The integration shipped despite a closed door. The lack of a SQL query would normally stall a direct connection; routing through Drive got the data flowing anyway.
• Manual and automated stayed one thing. Because the fallback runs the same rule, there was never a second workflow to maintain or a second mental model to learn.

Learnings

What worked. Using an Extensibility rule to drive the Import / Validate / Load API directly. The instinct is to reach for a connector, but a connector wants a query and a normal import step wants a human to pick a file — neither fits "run this unattended from a file." Feeding a byte array straight into the IVL API sidesteps both.

What I'd do differently. Nothing about the approach — but the connector-free, file-through-Drive pattern is general enough that it's worth reaching for early whenever a direct connection is blocked, rather than spending time trying to force the connection that isn't available.

Skill developed. Treating OneStream's Extensibility rules plus the Import/Validate/Load APIs as a way to build a load path when the platform's native connectors don't fit — and using a file-exchange middle layer to stand in for a connection a client can't expose.