When we build a OneStream application, one of the important things we need to control is where financial data gets loaded.
Let’s say we have 100 legal entities and 500 cost centers. The ERP sends actual financial data every month, and we map that data into OneStream.
Now, not every cost center belongs to every entity.
For example, an India entity may use cost centers 1001, 1002, and 1003, while a US entity uses a completely different set of cost centers.
So what happens when the source file contains a cost center that does not belong to the selected entity?
We need to make sure that invalid dimensional combinations do not get loaded into the financial model.
OneStream provides dimensional constraints for this requirement.
It also provides default member settings, but defaults serve a different purpose.
Let’s understand how both work and where we should use them during implementation.
What Are Dimensional Constraints in OneStream?
Dimensional constraints control which members from one dimension can be used with members from another dimension.
For example, let’s say UD1 represents Cost Center.
We have the following members:
India Cost Centers
1001 Finance
1002 IT
1003 Operations
US Cost Centers
2001 Finance
2002 IT
2003 Operations
Now, the India entity should not accept financial data against cost center 2001 because that cost center belongs to the US structure.
We can configure a UD1 Constraint on the India Entity member.
The constraint points to the permitted cost center member or hierarchy.
This restricts the valid UD1 members for that entity.
The same concept applies to other supported dimensions, including Flow and Intercompany.
Where Do We Configure Entity Constraints?
Entity constraints are configured through the Entity Dimension properties.
We open:
Application > Cube > Dimensions
Then we select the required Entity Dimension and Entity member.
The relevant properties are available under Vary By Cube Type.
OneStream provides properties such as:
- Flow Constraint
- IC Constraint
- UD1 Constraint through UD8 Constraint
These settings allow us to define which members are valid for that Entity.
For example, suppose we have:
Entity: IN001
UD1: Cost Center
We can configure UD1 Constraint to point to the India Cost Centers hierarchy.
The members under the selected hierarchy become the permitted members for that Entity, subject to the other applicable application settings.
This is more manageable than maintaining separate rules for every individual cost center when the hierarchy already represents the correct business structure.
How Constraints Work During Data Validation
Let’s take a practical integration example.
The ERP sends the following actuals.
| Entity | Cost Center | Account | Amount |
|---|---|---|---|
| IN001 | 1001 | 56000 | 15,000 |
| IN001 | 1002 | 56000 | 8,000 |
| IN001 | 2001 | 56000 | 12,000 |
The first two records contain cost centers that belong to India.
The third record contains a US cost center.
Now, let’s say we configure the Entity UD1 Constraint to allow only the India Cost Centers hierarchy.
The first two records use valid cost center members.
The third record violates the constraint.
OneStream uses dimensional constraints to control valid intersections. In the workflow and integration process, invalid dimensional combinations must be resolved before data is accepted into the required target intersection.
An important point here is that importing a file into the staging area is not the same as successfully loading valid financial data into the cube.
We need to check the validation results and the final load status.
Depending on the constraint configuration, OneStream may also mark intersections as unavailable for input in Cube Views.
Entity Constraints Versus Account Constraints
OneStream does not limit constraints to the Entity Dimension.
Account members also support dimensional constraints.
Let’s take another example.
Suppose we have an account called Travel Expense.
The business wants Travel Expense to be reported by Cost Center.
But another account, such as Share Capital, does not need the same cost center detail.
We can review the Account-level dimensional constraints to define which combinations are valid.
However, we should understand how Entity and Account constraints behave.
OneStream documentation explains that constraints applied to Account members can create invalid intersections that do not aggregate.
Entity constraints, on the other hand, can create no-input intersections.
These are not exactly the same behaviors.
So when we design dimensional controls, we need to understand whether we are restricting data input, preventing an invalid intersection, or controlling aggregation.
We should test the actual behavior in the application instead of assuming every constraint works in the same way.
What Are Default Members in OneStream?
Now, let’s look at default members.
A constraint restricts which member combinations are allowed.
A default member provides a predefined member that can be used when the integration or data-entry process references that default.
For example, suppose we have a financial integration that loads data for an Entity and Account, but the source system does not provide a Cost Center.
OneStream still needs a valid UD1 member in the final data intersection.
We may decide that the value should be loaded to a specific default member.
OneStream provides EntityDefault functionality for user-defined dimensions.
This allows an Entity to define a specific default UD member.
For example:
Entity: IN001
UD1 Default: 1001
When the configured integration maps UD1 to EntityDefault, OneStream can resolve the appropriate Cost Center from the Entity setting.
This avoids having to hard-code the same member separately for every Entity in the source mapping.
The important point is that the integration must be configured to use the default mechanism.
OneStream does not automatically choose the EntityDefault simply because the source value is blank.
Difference Between Constraint and Default Member
This is the main distinction we need to understand.
| Configuration | Purpose | Example |
|---|---|---|
| UD1 Constraint | Restricts allowed members | India entity uses India cost centers |
| UD1 Default | Resolves a configured fallback member | India entity defaults to cost center 1001 |
Let’s say we have an Entity with three valid cost centers.
The UD1 Constraint allows cost centers 1001, 1002, and 1003.
But the UD1 Default is 1001.
This does not mean that every financial record must be loaded to 1001.
If the source contains a valid cost center and the mapping uses that member, OneStream can load the data against that cost center.
The default is used when the configured mapping or input process references EntityDefault.
So we should not confuse the default setting with a restriction.
Example: Using EntityDefault in an Enterprise Integration
Let’s say we are integrating financial actuals from Workday Financials into OneStream.
The source data contains:
Company
Ledger Account
Accounting Period
Amount
Some records may also contain Cost Center.
Now, suppose the business wants certain company-level adjustments to be associated with an approved default cost center.
Instead of creating a separate transformation rule for every company, we can evaluate using EntityDefault.
For example:
IN001 defaults to Cost Center 1001.
US001 defaults to Cost Center 2001.
UK001 defaults to Cost Center 3001.
The integration maps the relevant UD dimension using the supported EntityDefault mechanism.
OneStream resolves the value based on the selected Entity’s configuration.
This can simplify maintenance when many entities follow the same integration pattern.
But we still need to validate the business requirement.
If cost center is mandatory in the source, we should not use a default simply to hide missing source data.
That would create a data-quality issue rather than solving one.
What Happens When the Default Is Incorrect?
Let’s say the India Entity has a default Cost Center of 1001.
Later, the organization changes its cost center structure.
Cost Center 1001 is no longer the correct default.
If the EntityDefault property is not updated, the integration may continue assigning data to the old member.
This is why default member maintenance must be part of the metadata governance process.
When a company introduces new departments, reorganizes cost centers, or changes entity ownership, we need to review the related default and constraint settings.
The ERP team and OneStream team should agree on how these changes are communicated.
Dimensional Constraints and Reporting
Constraints also affect how users work with data in Cube Views.
For example, if a dimensional combination is not allowed, the intersection may be marked as invalid or unavailable for input.
OneStream distinguishes between certain Account constraints and Entity or UD constraints.
The documentation explains that Account constraints can produce invalid intersections that do not aggregate.
Entity and UD1 constraints can produce no-input intersections.
The exact behavior depends on which dimension owns the constraint and how the application is configured.
This matters when users report that they can see a value but cannot enter data, or when certain member combinations do not return the expected result.
Before changing security or creating new members, we should check whether a dimensional constraint is controlling the intersection.
Performance Considerations
Default members can also affect the financial model.
OneStream documentation notes that EntityDefault and related user-defined dimension functionality can increase the number of data intersections involved in the application.
Depending on the design, this may affect consolidation processing.
For example, if we introduce default values across a large number of entities and user-defined dimensions, we need to understand how those values affect the stored data structure.
We should not use EntityDefault everywhere simply because it reduces the number of source mappings.
The right design depends on the reporting requirement and the number of resulting data cells.
For large applications, we need to test the effect on data loading, consolidation, and reporting.
What We Check During Implementation
When we configure dimensional constraints, we first review the approved Entity and cost center structure.
We identify which combinations are valid and whether the source system already maintains those relationships.
Next, we configure the relevant Entity or Account constraints.
Then we test the integration using both valid and invalid combinations.
For example, we should confirm that an India Entity can use an approved India cost center and that an invalid US cost center combination is handled correctly.
We also test default member behavior separately.
We confirm that the configured EntityDefault resolves to the expected member.
Finally, we reconcile the loaded data with the source.
The objective is to make sure that valid financial data is loaded to the correct intersection and invalid records are identified.
Common Design Issues
One common issue is using default members to compensate for incomplete source data without business approval.
For example, if the ERP does not send Cost Center, assigning every record to a default member may produce incorrect departmental reporting.
Another issue is setting constraints too broadly.
If the UD1 Constraint points to a high-level parent that contains every cost center, the configuration may not provide the intended restriction.
We also need to avoid setting constraints without testing data integration and reporting behavior.
A restriction that appears correct in the Dimension Library may affect other workflows or reports using the same members.
Finally, we need to maintain these settings when upstream metadata changes.
Constraints and defaults are not one-time configuration activities.
Conclusion
OneStream provides dimensional constraints and default member settings to help control how financial data is classified and used.
Constraints define which dimensional combinations are allowed.
Default members provide a way to resolve a configured member based on the selected Entity or another supported relationship.
Both are useful during enterprise implementations, but they solve different problems.
When we design integrations, we need to understand which values come from the source, which values should be mapped, and which values can be defaulted.
The most important point is that we should not use defaults to hide data-quality problems.
The configuration should follow the approved financial model and support accurate reporting.
Frequently Asked Questions
What are dimensional constraints in OneStream?
Dimensional constraints restrict which members from one dimension can be used with members from another dimension.
Where are Entity constraints configured?
Entity constraints are configured through Entity member properties, including the Vary By Cube Type settings.
What is EntityDefault in OneStream?
EntityDefault is a system member used with configured Entity default properties to resolve a user-defined dimension member.
What is the difference between a constraint and a default member?
A constraint restricts valid member combinations. A default resolves a configured member value.
Can OneStream restrict which cost centers an Entity can use?
Yes. If cost centers are modeled in a user-defined dimension, the relevant UD constraint can restrict the allowed members for an Entity.
Do defaults affect consolidation performance?
They can. OneStream documentation notes that default-member functionality may increase the number of data intersections and affect consolidation processing.