One of the toughest parts of training a new EDM user base is explaining why some properties apply to certain nodes and not others. As an administrator and the person who designed the system, it’s clear to me. As an end user, it can be frustrating to be told “that node doesn’t need every property, just ignore those fields.” Ignoring fields on a form just is not a great user experience.

In order to work around this, EDM developers have created separate node types within the same dimension which means each group of nodes gets its own set of properties. There are situations where that’s the right call, but it comes with baggage. Users need to decide which node type to create, administrators have more configuration to maintain, and the whole thing gets less intuitive.

That’s where the new Contextual Properties feature in the 26.09 release comes in.

What are Contextual Properties?

Contextual Properties let EDM decide which properties to display based on the value of a controlling property. Instead of showing every possible property to every user, the property pane adapts to the kind of node being maintained.

My favorite example is a Planning application where parent and base members share the same node type. We usually don’t want users assigning attribute values to parent members, since those attributes only mean something at the base level. With Contextual Properties, you define a context for Parent and Base, and each one only displays the properties it should.

How it works

The feature introduces the concept of a controlling property. This means the user defines the context values, associate properties with each one, and EDM updates the property pane when a user picks a value. Here’s what it looks like:

1. Create a new String property with the Basic subtype. I called mine “Context Property,” which is about as creative as I can get at the moment.
2. Add the property to a Node Type, then change the subtype to Context. The property can’t be derived or inherited.
3. On the Node Type, open the Context tab and assign your property as the controlling property.
4. Add your context values and assign the properties that belong to each one.

Let’s say I add two values to that property: Parent and Base. When the user selects Parent, only the parent-related properties appear. When they select Base, the leaf-member attributes show up.

The result is a property form that adapts to the node being maintained instead of forcing every node through the same experience.

Why This Matters

For me, the parent-versus-base node scenario is the most compelling use case. When we are managing EPM applications, there are certain properties that will apply to base nodes that really don’t need to be filled out or should not be filled out at the parent level.

This could also be applied to a “Site” or “Facility” node type. Certain types of sites or locations may need some properties and those values might not apply to a site of a different type. This is a perfect use case for those scenarios.

Better Validation Behavior

Custom validations with contextual properties are only going to get easier to create and maintain. Only properties associated with the active context are displayed and validated. This means required property checks only apply where they actually make sense. Parent nodes will no longer fail validations because they’re missing leaf-level attributes, and base members aren’t evaluated against rules intended for rollup nodes.

Administrative Benefits

The real value may be on the administration side. As mentioned earlier, many EDM implementations solved this problem by creating additional node types, node sets, and extra validation logic. Contextual properties promise to reduce the need for those workarounds.

One node type can now behave differently depending on the business context of the node. I’m a huge fan of keeping things simple where possible, and less configuration generally translates into less long-term maintenance, which is usually a win for me and my clients.

A Few Things to Know

There are a few implementation details worth understanding before rolling this into production.

1. Changing contexts does not remove existing property values. Hidden contextual properties are ignored during validation and request processing, but their values are preserved. This is similar to those “phantom” nodes when someone does a Remove action on a node with a single location. Just because you don’t see it doesn’t mean it’s not stored in the backend database.
2. Viewpoint downloads, extracts, and Universal exports include contextual property columns. However, values are only returned for properties that are active for the current context.
3. Imports behave differently than many people will expect. Replace and Reset load modes can process contextual property values regardless of the active context.

Final Thoughts

I think this is a great enhancement because it addresses a problem EDM administrators encounter on most implementations. For years, there was a tradeoff between keeping the model simple and keeping the user experience clean. Contextual properties are going to significantly reduce that tradeoff.

For me, that’s the real value of this enhancement. It isn’t just about hiding properties. It’s about making EDM easier for business users to navigate while reducing the need for administrators to create additional node types solely to control which properties are available for data entry.

References:

Configuring Contextual Properties: https://docs.oracle.com/en/cloud/saas/enterprise-data-management-cloud/dmcaa/context_control_prop_configure.html

Oracle EDM September 2026 (26.09) What’s New: https://docs.oracle.com/en/cloud/saas/readiness/epm/2026/edm-sep26/