Hi there – welcome to the first of (hopefully) several blog posts regarding the feature-packed 23.09 update of Oracle Enterprise Data Management! This feature is one of my favorites from this patch, and one we have been asking for, for what feels like years.

This release includes the Configurable Validation Severity for Custom Validations. Let’s walk through the feature and why it’s important.

Configuring a Custom Validation’s Severity

In this example, I’m going to add a custom validation on my PBCS_Account dimension. This is a simple example – any time I add a new Account I will be ensuring that the “Alias: Default” property does not include the word “HyperionBarbie“. I applied it to the Vizualized state vs. the Committed state, so my end user gets immediate feedback that the data entered will be caught by the validation.

The new feature, “Severity” appears at the bottom of the Validation setup and allows you to configure which request stages the validation is applied. There’s 3 options: Ignore, Warning, and Error. Previous to this update, the Severity was always the equivalent of Error.

You can see in this example, I chose to do a Warning on the Request Submit stage, but Error on both Approve and Commit.

Here’s the code for the Expression, again, a simple example to prevent users from entering the word “HyperionBarbie” into Alias: Default:

And finally, how it looks to the end user in the interface, when they do enter “HyperionBarbie” into the Alias: Default:

If you’ve been in EDM before, you know that Error validations that truly stop the Submission process, will appear at the bottom of the Hierarchy panel in a light red/pink color. You can see in the above screenshot that this new “Warning” Validation severity is a light orange in color, and includes a new icon that looks like a hazard/warning sign. This appears in the message itself, next to the node in the hierarchy panel, and in the request items on the left in the request.

Why is this Feature Important?

While Oracle has provided OOTB validations, adapter-specific OOTB validations, and custom validations in EDM since it was released, many times when creating workflow solutions for end-users, there were some instances that they could get ‘stuck’ by validations. In many of these cases, business users really shouldn’t have to know all of the properties/attribution to submit the request; and it would be up to an approver or data manager to update. The harsh gating that the “Error” validation oftentimes could be frustrating to users that only knew part of the required attribution or node placement/numbering – which either left them to call someone for help or use the Collaborate feature before submitting.

Now in these situations where the request submitter, or even approver, may not know all required attribution – but may or may not get warned that it was wrong – is possible. We can put the data quality “gates” in the right part of the request lifecycle.

Why is this important? It can help you expand your usage of EDM to more functional users that may not know all the ins-and-outs of attribution, but can still source or update data that they know – and allow for next layers of data stewards to apply the additional details to pass validations before the request is committed.

In short: EDM’s new custom validation severity options gives organizations more options to give data management back to the business and allows us to build more flexible workflows to meet their needs.