Enterprise Systems
OneStream Business Rules for Financial Data Imports: Connectors, Transformations and Reconciliation
Design maintainable OneStream import logic using connector and transformation rules, workflow context, batching, mapping and reconciliation controls.
OneStream gives implementation teams several places to define data-loading behavior. Data Sources describe how imports are parsed, Transformation Rules map source values into the target model, Workflow Profiles organize the loading process, and Business Rules can add reusable or custom logic where standard configuration is not enough. Start with the standard data-loading model Use standard configuration for requirements it expresses clearly. A useful mental model is source → Data Source/connector → staging → transformations → validate → load → reconcile . Custom code should solve a real requirement rather than hide mappings that could remain visible and maintainable. Keep connector rules narrow A connector rule should retrieve a predictable source population and expose a stable set of source fields to the import process. Workflow context can help determine entity/time scope. For large sources, make batching and retry behavior explicit. Keep transformation logic understandable Account, intercompany, entity, custom-dimension and sign transformations should be implemented in the simplest layer that fits the requirement. Business Rules are appropriate when normal mapping configuration cannot express the logic cleanly. Separate extraction, transformation and validation responsibilities A rule that retrieves data, changes dimensions, fixes signs and silently handles validation exceptions becomes difficult to test. Clear responsibilities make failures easier to isolate and reduce unintended side effects when one part changes. Use workflow context deliberately When the import is initiated from a specific workflow/entity/period, that context can help define the correct source query and transformation behavior. Document which workflow values influence extraction so the implementation remains explainable. Design batching for repeatability Define stable ordering/cursors, batch limits, retry behavior, duplicate protection and completeness checks. A batch strategy should support reconciliation rather than merely avoid request timeouts. Log enough to troubleshoot, not enough to leak Useful technical logs can record batch identifiers, source counts, transformation stages and error context. Avoid logging confidential financial rows or credentials simply because they are available to the rule. Reconciliation should survive rule changes After a transformation or connector rule changes, re-run source-to-target reconciliation using the same entity/period context. This turns validation into a repeatable regression process rather than a one-time go-live activity. When custom rules are justified source retrieval needs workflow-aware logic; standard transformation rules cannot express the requirement clearly; shared logic is reused across controlled import stages; custom validation or event behavior is required; the rule can be tested and documented independently. When configuration is better than code If a finance-facing mapping can be expressed clearly in normal transformation configuration, keeping it visible there may be easier to review and maintain than embedding it in custom code. Our anonymized SAP S/4HANA to OneStream case study demonstrates workflow-driven extraction, custom rule logic and reconciliation without exposing client-specific code or schemas. See OneStream Business Rules & Import Workflows and financial data reconciliation for related implementation services.