Validation is what keeps Oracle Fusion Cloud Enterprise Data Management (EDM, most of us still call it EDMCS) from becoming just a fancy way to move bad data faster. Every time a node is added, changed, or moved, EDM has the opportunity to check it against a set of rules before that change ever reaches a downstream application. Get validation right, and a typo in an account code, a missing required property, or a business-rule violation gets caught the moment it's entered instead of surfacing three systems downstream during a close.
Validations run any time data moves or changes in the application, including:
- Importing data from a file
- Exporting data to an external application (when "Validate before Export" is set to alert or discontinue on error)
- Manually entering changes directly in a viewpoint
- Loading a file of request changes into a viewpoint
- Validating an individual request item
- Validating a full request
- Validating a viewpoint
The Three Types of Validation in Oracle EDM
System Validations are the baseline checks Oracle enforces automatically on every application: things like preventing duplicate node types, or making sure a node isn't set as a descendant of itself. These run at the node, hierarchy, viewpoint, and property level, and they cannot be disabled or have their severity changed. They're always on.
Predefined (Application-Specific) Validations are created automatically when you register an application, and they enforce the requirements of that target system. For example, registering a Planning application enforces unique member names across all nodes; registering an Oracle Financials Cloud General Ledger application enforces that a node's end date falls after its start date. Unlike system validations, these are enabled by default but can be disabled, or have their severity level changed, at the dimension level, configured from the Validations tab of the dimension inspector.
Custom Validations are rules you build yourself to enforce business logic specific to your organization, at the application, dimension, node type, or hierarchy set level. This is where most of the interesting, organization-specific rules live: property dependencies, cross-field logic, naming conventions, anything Oracle's predefined rules don't already cover.
For a validation failure, you can generally set the severity to Error (blocks the operation until fixed), Warning (flags the issue but allows the request to continue), or, for predefined and custom validations, Ignore.
Configuring validations (enabling or disabling predefined rules, or creating custom ones) is an application-configuration task: Oracle requires Owner or Metadata Manager permission on the relevant dimension to create, edit, or delete a custom validation.
Validation in Action
Following along with screenshots? Rather than reproduce Oracle's copyrighted UI images, this walkthrough links to Oracle's official documentation, which is kept current with the Redwood interface. Oracle's Understanding Validations and Constraints reference walks through the validation screens described below.
Here's what a validation failure looks like in practice, using a real example from an account hierarchy build:
- A submitter creates a request to add a new node to the application. Any property marked with an asterisk (
*) in the request form is required and will be checked during validation. - When the request is submitted, EDM evaluates it against all applicable system, predefined, and custom validations and returns either a success message or a list of validation errors.
- In this example, the request initially failed because Description US, Account Type, and Start Date were required but left blank.
- A custom validation on the Name property enforced upper-case characters only, along with a maximum length restriction.
- A custom cross-field validation enforced a business rule across Summary Flag, Allow Posting, and Allow Budgeting: if Summary Flag is set to Yes, Allow Posting and Allow Budgeting must both be set to No; if Summary Flag is set to No, Allow Posting and Allow Budgeting must both be set to Yes.
That last rule is a good illustration of what custom validations are for: it isn't something Oracle enforces out of the box, but it reflects a real accounting constraint (summary/parent accounts shouldn't accept postings or budget entries), so the team encoded it directly into EDM rather than relying on every submitter to remember it.
For the current, Redwood-interface steps to configure validations in your own environment (including how to build a custom validation expression), see Oracle's documentation:
- Understanding Validations and Constraints
- System Validations
- Enforcing Application-Specific Validations
- Working with Custom Validations
Why It's Worth Investing In
Validation is one of the highest-leverage things you can configure in EDM. A handful of well-designed custom validations, layered on top of Oracle's system and predefined checks, can catch the majority of data-entry errors before they ever leave the request stage, long before they'd otherwise surface as a broken rollup in FCCS, a rejected load in the general ledger, or a reconciliation break in ARCS.
If you'd like help auditing your current validation setup or designing custom rules for your chart of accounts, entities, or other dimensions, contact us for a free consultation.
Related reading: our overview of Oracle Enterprise Data Management covers where validation fits alongside node types, hierarchies, and requests, and our subscription walkthrough shows validation running as part of an automated request flow.