The 21.10 EPM monthly release brought us 18 new features for EDM alone. The Oracle Product Development Team has been busy adding new features to enhance future scalability and facilitate business processing.

Today I’d like to talk about a new feature that facilitates enforcing governance & business process, and is a net-new feature: it didn’t exist in legacy DRM/DRG. The days of finding parity between on-premise and cloud are coming to a close, and EDM is beginning to raise the bar from its legacy ancestor.

What is a Blackout Period

The term “Blackout Period” is more often associated with preventing insider trading. However, at its core a Blackout Period is a time where specific actions or changes is limited to minimize risk.

In Accounting & Finance, one of the most critical time periods is during close – where the final journal entries are run, books need to balance, and reports are run for executives and the street. This can be a stressful time; and you can imagine the importance of financial results being correct.

This is why a COA / mapping Blackout Period is so important: minimize change (risk) to improve correctness.

Configuring a Blackout Period in EDM

In EDM, the Blackout Period settings are on the Application level. This means that the entire Application adapter will use the same Blackout for all Dimensions.

Choose and application and click Inspect. On the first tab, General, press Edit in the top right to change the Blackout Period settings.

Configuration of Blackout Period on an Application Adapter

Blackout Period Settings:

  1. Enable Blackout – turns the Blackout Period on and off
  2. Start and end date of the Blackout Period. Here I’ve selected the first 10 days of October close.
    • Note, it shows you the Time Zone – important consideration for Global EDM customers.
  3. Allow Exceptions – you can allow Application Owners or Data Managers to make changes during the Blackout Period. This provides a little flexibility if you do run into a necessary change, in which a workflow needs to be invoked.
  4. Block Unbound Objects – this applies the Blackout to Requests that occur on Unbound objects. By default, all Bound objects fall under an active Blackout Period.

Once a Blackout Period is set, any Request for an Application that goes through its workflow will go into a new status, called “Blocked”. When a Request is marked as “Blocked” – it is stuck until the Blackout Period is over or the Enabled flag on the Blackout Period is disabled. Users cannot push it back, withdraw approval, or recall the request. You can, however, add comments and upload attachments.

Once the Blackout Period is lifted, any Requests that have been in Blocked status will commit to the application, in the order in which they were Blocked. Requests will layer ontop of one another and commit to the dimension structure, as long as there are no validation issues.

Link to Oracle documentation for Blackout Period configuration.


With any business process change comes a list of considerations. This feature has a few interesting quirks that should be considered before you deploy it in your close process.

  1. If you have a Request that has multiple items that span multiple applications, if one application is in Blackout Period – the entire requests will be put into Blocked status until the Blackout Period is over. This means you need to be strategic about what items are in each request so you do not hold up a request for a non-Blackout application, or end up duplicating request items.
  2. If a Blackout Period is active, you cannot import dimension data into EDM for that application. You can also not bind any unbound viewpoints to a dimension in the application at this time (probably pretty rare, anyway :))
  3. If there are any validation errors once the Blackout Period ends, the request will return to the state BEFORE blocked status and return to the submitter. This would likely happen due to another Blocked request that changed the data that was committed prior to the validation-error flagged request. This would be items like: (1) the request had the same proposed change as a request that already was committed, (2) the request is trying to add a new member to a parent that was deleted, or (3) a prior request changed the way a validation would be running on the data (child becoming a parent, etc.).

You can read more about Blackout Period considerations from Oracle here.

While Blackout Period is a great feature, it does have some room for enhancement. Personally, a few ideas that I need to put out on Cloud Customer Connect’s Idea Lab:

  1. Enable a recurring feature so the blackout period could be automatically enabled at the same time period every month (i.e. first 5 days of the month, etc.) – and obviously being able to edit or adjust the recurrence should be allowed.
  2. Allow for Dimension-level granularity on Blackout Periods. I can see the need where Accounts may need to be added throughout the close cycle, but the application would like to Blackout or hold changes on re-roganizations of Cost Centers or Departments until the reports are complete.

Thanks for reading! If you have any ideas for future blogs or questions contact me at @HyperionBarbie on Twitter or