The Inbox/Outbox is Oracle EPM Cloud’s managed file storage — the designated area within the EPM Cloud environment where external files are staged for import into the EPM application and where EPM-generated output files are staged for external retrieval. The Inbox holds files uploaded by the EPM Automate uploadFile command or through the EPM Cloud web interface — data files for import, dimension metadata files, LCM migration packages, and Application Snapshots for restore. The Outbox holds files generated by EPM operations — data exports from the exportData command, Application Snapshot exports from exportSnapshot, LCM exports, and Financial Reporting output files. The Inbox/Outbox replaces the direct file system access that on-premise Hyperion administrators used to place files on the Hyperion server — in Oracle EPM Cloud, there is no direct server file system access; all file operations go through the Inbox/Outbox mechanism.
Inbox/Outbox Operations
| Operation | Direction | EPM Automate Command | File Location |
|---|---|---|---|
| Upload data file for import | External → EPM Cloud | uploadFile | Inbox (profserv/Inbox/) |
| Upload metadata file for dimension import | External → EPM Cloud | uploadFile | Inbox |
| Upload LCM package for migration | External → EPM Cloud | uploadFile | Inbox (migrations/) |
| Export data from EPM to file | EPM Cloud → External | exportData then downloadFile | Outbox (profserv/Outbox/) |
| Export Application Snapshot | EPM Cloud → External | exportSnapshot then downloadFile | Outbox (snapshots/) |
| Export LCM package | EPM Cloud → External | exportSnapshot (or export migration) then downloadFile | Outbox (migrations/) |
File Retention and the Close Cycle
Oracle EPM Cloud’s Inbox/Outbox has a defined file retention policy: files in the Inbox are typically retained for 24 hours after they are consumed by an import operation; files in the Outbox are retained for a defined period (typically 60 hours for data exports, longer for snapshots). This retention behaviour has a specific implication for close cycle automation: an automation script that uploads a data file in the afternoon, runs the data import job, and then attempts to download the import log file twelve hours later may find that the log file has been removed from the Outbox if the retention period has elapsed. Automation scripts must download output files — logs, export files, snapshots — promptly after they are generated, not on a deferred schedule that may exceed the retention period.
Inbox/Outbox and the Integration Agent
Oracle’s EPM Integration Agent — the on-premise component that enables EPM Cloud to connect to on-premise data sources — uses the Inbox/Outbox as the staging point for data files generated by on-premise extracts. When the Integration Agent extracts data from an on-premise ERP, it places the extract file in the EPM Cloud Inbox through a secure connection, and the EPM Cloud’s Data Management job then imports from the Inbox. This mechanism allows on-premise ERP data to flow into EPM Cloud without requiring the on-premise system to expose its database to a public network — the Integration Agent makes the outbound upload, and no inbound connection to the on-premise environment is required.
What Goes Wrong in Practice
The specific Inbox/Outbox failure that most commonly disrupts close cycle automation is a file naming conflict — an automation script that uploads a data file with the same name as a file already in the Inbox from a prior run. EPM Cloud’s Inbox does not automatically rename or version uploaded files; a new upload with the same filename overwrites the existing file. If the prior period’s data file has not been consumed or removed before the current period’s file is uploaded with the same name, the prior period’s data is silently overwritten. Automation scripts should include a step to remove or rename files in the Inbox after successful import, and should use period-specific filenames to prevent accidental overwrite.
How Loop Wise Solutions Designs Inbox/Outbox Automation
Every close cycle automation we design includes explicit Inbox/Outbox file management steps — purging consumed files from the Inbox after successful import, downloading output files from the Outbox immediately after generation, and using period-date-stamped filenames for all uploaded files. These practices prevent the file retention and naming conflict issues that produce silent data errors in production automation runs.
Answers before you ask.
They are the managed file storage area within EPM Cloud. Files uploaded for processing — data loads, metadata imports, LCM migrations — go to the Inbox; output files such as data exports, snapshots, and reports are placed in the Outbox for download. It is the staging area between external systems and the application.
Because automated close and data routines move files through it — an EPM Automate script uploads a data file to the Inbox, runs the load, then downloads results from the Outbox. Reliable automation depends on understanding how files are placed, referenced, and cleaned up, so scripts pick up the right file and do not fail on a missing or stale one.
Files in the Inbox/Outbox are subject to retention policies and are not permanent storage. Automation should not assume a file placed today will remain indefinitely; scripts should upload, process, and retrieve within the cycle and archive anything needed long-term externally. Overlooking retention is a common cause of automation that works once then fails later.
Through the application interface and, for automation, via EPM Automate commands and the REST API that upload and download files to and from it. This programmatic access is what lets scheduled routines stage inputs and collect outputs without manual handling, making the Inbox/Outbox the file backbone of EPM Cloud automation.