Dynamic Period Locking Using Smart List in Oracle EPM (using Groovy Rule)

Have you ever faced the challenge where business users need flexibility to edit data in some months, but strict control in others? This is a common scenario in Oracle EPM Planning, and managing it manually can quickly become a headache. Luckily, there’s a way to automate this process using Smart Lists combined with a Groovy rule—making your forms dynamic, business-controlled, and much more efficient.

 

Let’s dive into how this solution works and why it’s so powerful.

 

**Business Requirement**

Here’s the goal: We want a Smart List column (let’s call it Account = SL) that acts as a simple toggle for whether a month is editable. If the user selects “DoNotUpdate” for a month, then certain accounts (like A_77300 and A_77600) should become read-only for that period—while other months remain editable. This puts the control squarely in the hands of your business users, without the need for IT to lock and unlock forms each month.

 

**The Solution: A Smart List-Driven Groovy Rule**

 

Our approach is to create a Groovy business rule that runs *before* the form loads. The rule works in two passes:

 

**Configuration Section**

final String CONTROL_ACCOUNT  = "SL"

final String SMARTLIST_NAME   = "SL"

final String LOCK_VALUE_NAME  = "DoNotUpdate"

final Set<String> TARGET_ACCOUNTS = ["A_77300","A_77600"] as Set

 

Here’s what these variables do:

 

- **CONTROL_ACCOUNT:** The account that holds your Smart List selection

- **SMARTLIST_NAME:** The Smart List assigned to that account

- **LOCK_VALUE_NAME:** The Smart List value that triggers the lock (“DoNotUpdate”)

- **TARGET_ACCOUNTS:** The set of accounts you want to lock (easily expandable!)

 

**Pass 1 — Identify Which Periods to Lock**

 

First, the rule scans the grid to check which periods have the Smart List set to “DoNotUpdate.” It does this by iterating over data cells, but only in the SL account (our control column). Since Smart Lists use numeric keys, the rule converts the stored value to retrieve the actual entry. If the entry is “DoNotUpdate,” that period is added to a set called `periodsToLock`.

 

Example after Pass 1: `periodsToLock = [Feb]`

 

**Pass 2 — Lock the Target Accounts**

 

Now, the rule loops over the grid again. This time, it skips the Smart List column and focuses only on the target accounts. For each account and period, if the period is in `periodsToLock`, the cell is set to read-only.

 

Here’s the locking logic in action:

 

if (periodsToLock.contains(periodName)) {

    if (TARGET_ACCOUNTS.contains(acc)) {

        cell.setForceReadOnly(true)

    }

}

 

This means those cells are still visible to users but can’t be edited—without affecting other accounts or periods.

 

**What Does This Look Like on the Form?**

 

| Period | SL           | A_77300   | A_77600   |

|--------|--------------|-----------|-----------|

| Jan    | Update       | Editable  | Editable  |

| Feb    | DoNotUpdate  | 🔒 Locked | 🔒 Locked |

| Mar    | (blank)      | Editable  | Editable  |

 

Everything happens automatically when the form loads—no manual intervention required.

 

**Why This Approach is powerfull**

 

- **Empowers business users** to control data entry at a granular level

- **Reduces IT effort** and risk of manual mistakes

- **Easily extendable**—add more accounts or lock values as your requirements grow

- **Keeps your forms dynamic** and responsive to real-world needs

 

If you’re looking for a smart, scalable way to manage data-entry permissions in Oracle EPM Planning, this approach is a game-changer. The Complete Rule is here

Happy automating!