When we design a OneStream application, the business often wants to analyze financial data in different ways.
For example, a company may load revenue by Product, but management also wants to see revenue by Product Category.
The categories may be Retail, Wholesale, and Consumer.
Now, the source ERP may provide Product codes but may not provide a separate Product Category field for every transaction.
So do we need to create another integration and load the same revenue data again by Product Category?
Not necessarily.
OneStream provides Attribute Members in user-defined dimensions. These allow us to create analytical groupings based on the properties of existing dimension members.
Let’s look at how Attribute Members work and where they can help in an enterprise financial model.
What Are Attribute Members in OneStream?
An Attribute Member is a user-defined dimension member that derives its values from the properties of members in a related dimension.
Unlike a normal input member, an Attribute Member does not store financial data directly.
Instead, OneStream evaluates the configured relationship and returns the relevant data when the member is used in reporting.
For example, suppose we use UD2 for Products.
We have five Product members:
| Product | Product Category |
|---|---|
| P01 | Retail |
| P02 | Retail |
| P03 | Wholesale |
| P04 | Retail |
| P05 | Consumer |
The Product Category can be maintained in a Text property of each Product member.
Now, suppose the business wants to see total Retail sales.
We can configure an Attribute Member to identify the Product members whose category is Retail.
OneStream derives the result from those Product members.
We do not need to load a second copy of the financial data under Retail.
Why We Use Attribute Members
Let’s take a larger enterprise example.
We are implementing OneStream for a company with 2,000 products.
The ERP provides transactions by Product code.
However, the business wants to analyze revenue by Product Category, Brand, and other classifications.
One option is to include each classification in the data integration and store the relevant values at separate dimensional intersections.
That can be appropriate when those classifications must be part of the stored financial model.
But sometimes the requirement is only analytical.
The finance team wants to group existing Product data using information already maintained in metadata.
In that case, Attribute Members may provide a simpler option.
We can use the properties of existing Product members to derive the required reporting groups.
The important point is that we are not creating another independent set of stored financial values.
We are creating a different way to analyze the existing data.
How Attribute Members Work
Let’s continue with the Product example.
UD2 contains the Product members, and their Text1 properties contain the Product Category.
For example:
P01 has Text1 = Retail.
P02 has Text1 = Retail.
P03 has Text1 = Wholesale.
P04 has Text1 = Retail.
P05 has Text1 = Consumer.
We then use another suitable UD dimension to create Attribute Members.
For example, we may use UD5.
Under UD5, we create:
Retail
Wholesale
Consumer
These are analytical members.
We configure each member to reference the appropriate property in the Product dimension.
For the Retail Attribute Member, the configuration identifies members where the relevant UD2 Text1 property equals Retail.
OneStream evaluates the matching Product members and derives the corresponding financial result.
Example: Reporting Revenue by Product Category
Let’s say we have the following Product revenue for January.
| Product | Category | Revenue |
|---|---|---|
| P01 | Retail | 1,000 |
| P02 | Retail | 1,500 |
| P03 | Wholesale | 1,200 |
| P04 | Retail | 900 |
| P05 | Consumer | 1,400 |
| Total | 6,000 |
Now, management wants the same revenue reported by category.
Using the Attribute Member configuration, the result can be:
| Category | Revenue |
|---|---|
| Retail | 3,400 |
| Wholesale | 1,200 |
| Consumer | 1,400 |
| Total | 6,000 |
The values are illustrative.
The main point is that the category report derives its results from the existing Product data.
We do not need to submit another 6,000 of revenue into separate category intersections.
This helps us avoid duplicating the same information for an analytical reporting requirement.
How We Configure Attribute Members
Attribute Members are configured in the Dimension Library.
We open the relevant User Defined Dimension and create the required member.
Under the member settings, OneStream provides a property called Is Attribute Member.
We set this property to True.
This enables the attribute-specific configuration.
Several properties then become important.
Source Member For Data
This identifies the base member in the attribute dimension from which the data is referenced.
For example, if UD5 is our analytical dimension and the source financial data is stored at UD5 None, we may use None as the source member.
OneStream requires this to be a base-level member. A parent member cannot be selected for this property.
Comparison Dimension
This identifies the related dimension containing the members we want to classify.
In our example, this is UD2 because UD2 contains Products.
Comparison Property
This identifies the member property used for classification.
OneStream supports properties such as Name, Description, and Text fields.
For our example, we use Text1.
Comparison Text
This identifies the value being matched.
For the Retail Attribute Member, we use Retail.
Comparison Operator
This defines how OneStream compares the property with the text.
The available comparisons include Equals, Not Equals, Starts With, Ends With, Contains, and Does Not Contain.
In our example, we use Equals.
Once configured, OneStream derives the matching data when the Attribute Member is referenced.
Can We Use More Than One Classification Condition?
Yes.
OneStream supports attribute expressions that compare one or two related dimensions.
For example, we may want to analyze products based on two different conditions.
The configuration can use:
Comparison 1 Only
Comparison 1 and Comparison 2
Comparison 1 or Comparison 2
This allows an Attribute Member to represent a more specific reporting group.
For example, we may need a group that includes members meeting both a Product classification and another approved metadata condition.
However, this does not replace the need to design the related UD dimensions correctly.
We need to confirm that the source members, comparison properties, and reporting intersections support the intended result.
What Happens When a New Product Is Added?
Now, let’s say the ERP introduces a new Product called P06.
The Product belongs to the Retail category.
We create the Product member in the appropriate OneStream dimension and maintain its category property.
For example:
P06
Text1 = Retail
If the existing Retail Attribute Member is configured to match that Text1 value, the new Product can be included in the derived Retail result.
We do not need to edit a hard-coded list of Product codes inside the Attribute Member every time a new Retail Product is introduced.
This can simplify metadata maintenance.
However, the classification property must be maintained correctly.
If someone creates P06 but forgets to assign the Retail classification, the Product may not appear in the expected category analysis.
So we still need metadata governance.
Attribute Members and Consolidation Performance
Another useful point is how Attribute Members behave in the financial model.
OneStream documentation explains that Attribute Members derive their data dynamically.
They do not store another copy of the financial values.
The documentation also states that Attribute Members do not increase the size of the Data Unit during consolidation.
This can be useful when the business needs additional analysis without storing more financial intersections.
However, we should not assume that every report using Attribute Members is automatically faster.
The reporting process still needs to evaluate the configured attribute conditions.
The actual performance depends on the application design, member properties, reporting queries, and data volume.
We need to test the result for large reporting requirements.
What Is the Difference Between an Attribute Member and a Normal UD Member?
This is an important design distinction.
A normal UD member can be used as part of a stored data intersection.
For example, Product P01 may be a normal UD member where revenue data is loaded.
An Attribute Member is different.
We do not load revenue directly into Retail.
OneStream derives Retail revenue by evaluating the configured relationships against the source Product members.
So the normal member identifies where data is stored.
The Attribute Member provides an additional analytical classification of that data.
This difference matters when designing integrations and reporting.
Attribute Members and Historical Reporting
This is one area we need to be careful with in enterprise applications.
Suppose Product P01 is classified as Retail in 2026.
Later, the business changes its classification to Consumer.
Now, what should happen to the historical Retail report?
If the Attribute Member uses a current Text property that changes, the derived results may also change.
OneStream documentation explicitly states that Attribute Member results are dynamic and can be affected by changes to related member properties.
The financial data itself may remain unchanged, but the reporting classification can change.
This means Attribute Members are not automatically suitable for every historical reporting requirement.
For example, if the business needs an approved historical report to retain the exact Product classification used at the time of closing, we need to design how that classification is maintained.
OneStream Text properties can vary by Scenario and Time in supported configurations, but we still need to confirm whether that approach satisfies the audit requirement.
We should not rely on current metadata properties when the business requires a fixed historical classification.
Reporting and Drill-Down Considerations
Attribute Members can be used in Cube Views and other supported reporting contexts.
They can help users analyze results without requiring a second stored data set.
However, OneStream documents some limitations.
For example, an Attribute Member does not accept direct input.
Attribute values are not extracted as normal stored data records.
Also, drilling back to Stage Load Results from an Attribute Member intersection is not supported in the same way as from its underlying source member.
If users need detailed source-level reconciliation, they may need to navigate to the underlying data member.
This is important when deciding whether an Attribute Member is suitable for an operational reconciliation report or primarily for management analysis.
What We Check Before Using Attribute Members
During design, we first identify what the business wants to analyze.
For example, does the finance team need Product Category only for reporting, or does it need to load, allocate, and adjust data at Product Category level?
If the category is mainly analytical, we can evaluate Attribute Members.
Next, we confirm where the classification is maintained.
Does the ERP provide it? Is it available as a member property? Who owns the classification?
Then we define how the attribute matches members and what happens when the classification changes.
We also review historical reporting requirements.
Finally, we validate the Attribute Member totals against the source Product data.
The report should return the expected members and financial results.
We should test new Product creation and changes to classification properties before using the design in production.
Common Design Issues
One common mistake is using an Attribute Member where the business actually needs a stored data dimension.
For example, if users need to input financial adjustments directly by category, Attribute Members alone do not provide that input capability.
Another issue is not maintaining the classification properties consistently.
If Product members have missing or incorrect Text values, the derived reporting groups may be incomplete.
We also need to avoid assuming that Attribute Member results are fixed historical values.
Changes to metadata can affect the output.
Finally, we should not use the feature without checking the reporting and drill-down requirements.
Some analysis is better handled through a normal UD structure.
Conclusion
OneStream Attribute Members provide a way to analyze existing financial data using the properties of related dimension members.
They are useful when the business needs additional reporting classifications without creating another set of stored financial data.
For example, we can group Product revenue by Retail, Wholesale, or Consumer using the existing Product members and their metadata properties.
But we need to understand the limitations.
Attribute Members are read-only, their results are dynamic, and changes to metadata can affect historical reporting.
For enterprise implementations, we should use them when the requirement is analytical and the business accepts the dynamic classification behavior.
The objective is to support flexible reporting without adding unnecessary complexity to the financial model.
Frequently Asked Questions
What is an Attribute Member in OneStream?
An Attribute Member is a user-defined dimension member that dynamically derives its values from the properties of members in a related dimension.
Can we load data directly to an Attribute Member?
No. Attribute Members are read-only and do not accept direct data input.
Which properties can Attribute Members use?
OneStream supports comparisons against member Name, Description, and Text properties.
Do Attribute Members increase consolidation Data Unit size?
OneStream documentation states that Attribute Members do not increase Data Unit size during consolidation.
Can Attribute Members use two conditions?
Yes. OneStream supports two comparison conditions using AND or OR logic.
Can changing a Product classification affect historical results?
Yes. Attribute Member results are dynamic. Changing related member properties may affect previously reported classifications unless the design preserves the required historical context.