Oracle EDM is a perfect tool for managing and distributing dimension members and mapping rules across your Oracle EPM landscape & beyond. One of the most common points of confusion during implementation is this: should your mappings live on an Oracle EPM application, or on a Universal application? And once you’ve decided that, should you use a native Export or a custom Extract to push those mappings into Data Exchange?

Let’s walk through the why EDM for mapping, configuration considerations, and the integration patterns for each path.

Before choosing between application types and export methods, it’s worth grounding the decision in what EDM brings to mapping management. Maintaining mappings directly inside Data Management (without EDM) creates a fragmented, hard-to-govern environment — each EPM application holds its own mapping tables with no central visibility, workflow, or audit trail.

EDM addresses this by serving as a governed hub. Key benefits include:

  • Scalable mapping a single mapping set in EDM can be distributed to multiple target systems with minimal integration effort.
  • Governance and workflow just as EDM enforces approval processes for dimension changes, it can enforce workflow and approval for mapping change requests, controlling who submits changes and under what conditions.
  • Robust audit trail every mapping change request is tracked and stored in EDM, including who made the change, when, and through what approval flow. Member-level mapping history is preserved.
  • Collaborative interface mapping change requests can leverage comments, attachments, and collaboration features, and conditional routing can ensure the right subject matter experts participate.
 Key Consideration
Using EDM for Oracle EPM mapping introduces an additional integration layer: mappings must be pushed from EDM to the target application needing them. Bringing source metadata into EDM solely for mapping purposes may also increase record count for licensing, if you aren’t using a legacy node type. Plan for this to assist during scoping & design.

Data Exchange (fka Cloud Data Management) in Oracle EPM supports multiple mapping types. Understanding these is essential before choosing your EDM setup, because not all types are supported by every EDM approach:

  • Explicit are classic one-to-one mappings; a single source value translates to a specific target member. This is the simplest and most common type.
  • Between mappings include a range of source values mapped to a single target member.
  • In are a “cherry picked” list of specific source members mapped to one target member.
  • Multi-Dimensional maps a target member based on a combination of multiple source dimensions (ex: This legacy Account/Entity Combo goes to this new Account)
  • Like wildcard mappings using * and ? characters; also supports SQL-style format masks. This allows you to apply a mapping to many rows with the same criteria. Most commonly, we use this to map a prefix to all source members (Account 1000 x like mapping A* = target account A1000).

Execution order: Explicit > Between > In > Multi-Dimension > Like. Understanding this order matters when building mappings.

SQL Mapping – Not Super Compatible with EDM SQL conditional mapping is difficult to store in EDM due to the formatting of the clauses. EDM does not format SQL logic into a consumable structure for Data Exchange import. SQL mappings should be maintained directly in Data Exchange.

When you create an application in EDM, you choose a type. For mapping integrations, the two primary paths are Oracle EPM Applications (bound to a specific EPM target like Planning or FCCS) and Universal Applications — or an unbound dimension added to either application type — which are flexible, schema-agnostic containers.

Oracle EPM Application – Native Oracle EPM Mapping

As you may know from a previous blog post, Oracle has several delivered Application types that you can select, many of which are for Oracle EPM target applications. The applications in pink below are EPM applications that allow you to set up mappings and export them directly to the Inbox/Outbox of the Oracle EPM application if you have a direct connection set up.

You can also set up mappings on a Universal application with more options, which we will get into more detail in a bit.

As I stated above, when your dimension lives inside an Oracle EPM Application in EDM, you get access to the native Export Dimension Mapping function. EDM’s delivered mapping functionality supports Explicit mappings between source and target dimensions through Mapping Viewpoints, which are laid out in parent-child format, source members map to target members through parent-child relationships.

This native export leverages the application’s built-in connection to push a pre-formatted CSV file directly to the target EPM application’s Data Exchange inbox folder. No manual file design is required. Additionally, the same Oracle EPM Application Connection can be used to transfer the mappings that common dimension metadata uses for the delivered Import/Export features.

Setting up Explicit mappings on an Oracle application involves three components:

  • Mapping Node Type(s) created and bound to the target application to allow conversion of source node types to the target application for mapping.
  • Map Bindings defined on the target application to specify which node types are being mapped for different tables.
  • Mapping Keys specified on each Map Binding to define locations for exporting mapping between source and target node types, including the Data Management location name that drives where the file lands.
Pros
– Built-in file formatting compatible with Data Exchange

– Delivered application connection handles transport directly to the EPM inbox

– Supports core mapping scenarios: COA explicit mapping, segment-to-segment mapping
Cons
– Only supports Explicit mapping types, no Like, Multi-Dim, Between, or In

– File format is fixed and cannot be reshaped for other usage, may need to create an EDM Extract for other systems

Universal Application or Unbound Dimension Mapping – Custom Extract flexibility

When you need mapping types beyond Explicit, including Like, Multi-Dim, Between, or In, the solution is to manage mappings inside a Universal Application, or to create an unbound dimension within an existing Oracle or Universal application.

Per Oracle’s documentation, Unbound Dimensions are created outside of the application registration process and are not available in the delivered Export Mapping option. Data is loaded into an unbound dimension viewpoint using request load files, and mapping data is pulled out using custom Extracts. This is similar to setting up a mapping viewpoint in a Universal application, as you are defining the data chain and properties from scratch, rather than relying on the Export logic of the Export Mapping option on an Oracle application.

For both Universal & Unbound dimensions, you design the Extract to format and deliver the file exactly as Data Exchange requires, or any other solution that is non-Oracle that needs the mapping.

Finally, because Universal applications & Unbound dimensions require Extracts and can’t use the Connection, you can set up a Global Connection to use for integration support.

As you are creating the Node Types, Hierarchy Sets, and Node Sets from scratch, you can define if you want different properties for different map types (add properties for Multi-Dims, for example) or define your own logic. Many times when using this approach I like to have different node types for each type of mapping, and then include the properties that are required for that type. It also allows you to create validations by Node Type that are valid for that type of mapping (ex: If you have a Multi-Dim mapping, you need to define both Dimension 1 and Dimension 2 via Node Type properties to source dimensions; requiring the user to fill in the entire mapping).

Pros
– Supports most mapping types: Explicit, Like, Multi-Dim, Between, In, and more

– Full control over output file structure via custom Extract design

– Node Type Properties enable segment-to-segment and COA mapping elegantly

– Mapping sets can be shared across multiple target platforms with minimal effort

– Reusable across multiple target environments / application types
Cons
– Cannot use the application’s native delivered connection, unbound dimensions and Universal applications are not supported by the Export Dimension Mapping function

– You must design the extract file to match Data Exchange’s format requirements

– More EPM Pipeline configuration file Operations job type often needed to move files from EDM staging

– Higher setup effort

Good Rule of Thumb: If your mapping requirements are limited to Explicit mappings and you’re integrating with a standard Oracle EPM target, start with the Oracle application approach, it’s simpler and lower risk. If complexity grows (Like, Multi-Dim, or COA combination mappings), the Universal application or unbound dimension path is the right choice.

The last item on this list is to define the EPM Automate and/or Pipeline integration patterns that are needed for each option. The table below summarizes the combination of application type, method, connection type, and pipeline job type for both the EDM outbound side and the EPM ingestion side for the mappings. Use this as a reference when designing & building your integrations:

EDM Application TypeEDM Method to Get Mapping OutEDM Side – Connection TypeEDM Side – EPM Automate CommandEDM Side – Pipeline Job TypeMapping types supportedEPM Side – Pipeline Job TypeEPM Side – EPM Automate
Oracle EPM ApplicationExportDelivered Application Connection (defined within EDM EPM Application)Export Dimension MappingExport Dimension Mapping by Name Explicit onlyImport MappingImport Mapping
Universal ApplicationExtractGlobal Connection Extract DimensionExtract Dimension Viewpoint Explicit, Like, Multi-Dim, Between, In, customImport MappingImport Mapping
Oracle EPM Application with Unbound DimensionExtractGlobal Connection Extract DimensionExtract Dimension Viewpoint Explicit, Like, Multi-Dim, Between, In, customImport MappingImport Mapping


Of course, there are many other considerations when designing your mapping flows and final output, like Governance, Viewpoint design, and Permissions. But on the integration side, hopefully the considerations and design patterns in this post will help you determine the best path forward.

Thanks for reading! Leave your best tips for EDM/EPM Integrations in the comments!