CLS / DataMap self-service in EPBCS

Every close cycle, someone in finance needs a forecast locked, a budget reopened for a late adjustment, or a data map run to move numbers between cubes. In a lot of EPBCS implementations, none of those are things a finance user can do for themselves. They log a request, an administrator picks it up when they can, and the task sits in a queue. The governance is fine. The waiting is the problem.

We recently built a way around that for a client’s Central Finance group, the senior finance power users who own the numbers but do not, and should not, hold administrator roles in the application. They can now toggle Cell Level Security locks on and off, and trigger DataMap executions on demand, without anyone widening their access. The privileged work still happens under an administrative context. The users just do not carry the privilege themselves.

The constraint we were working inside

The brief had two halves that usually pull against each other. Finance wanted to stop depending on administrators for routine operational tasks. Security and audit wanted no new roles handed out and no broadening of who could change the application’s configuration.

The usual answer to the first half is to grant more access. That fails the second half immediately. So the design started from the opposite end: keep every user’s access exactly as it is, and move the privilege into the system instead of onto the person.

A controlled execution layer

The mechanism is a Groovy business rule sitting in front of a secured connection.

A user launches the rule from a form or the rule launcher, the same way they would run any calculation. The rule does not act with the user’s permissions. It calls the EPM Cloud REST API through a connection that has been configured separately with service credentials. Those credentials carry the administrative rights. The user never sees them and never holds them. Their only interaction is choosing an action and pressing a button.

We implemented two capabilities on this pattern, kept deliberately separate so each stays simple to reason about and maintain.

Toggling Cell Level Security on demand

The first capability lets a user enable or disable a data lock, a Forecast or Budget lock, and have it take effect straight away with no administrator in the loop.

When the user runs the rule, it builds a Cell Level Security definition for the one rule that is being changed, sets that rule’s enabled flag according to the user’s choice, and submits a security import job through the Jobs API on the secured connection. The lock applies immediately, across both web forms and Smart View.

The design decision worth calling out is scope. The rule rebuilds only the specific CLS rule it is responsible for, rather than exporting the whole security model, changing one flag, and re-importing everything. Keeping the footprint to a single rule means the operation cannot disturb any other security definition, it runs quickly, and if something ever does go wrong the affected surface is one rule rather than the entire configuration. It also keeps the behaviour predictable: the same input always produces the same narrow change.

Running DataMaps without admin access

The second capability is simpler. A user triggers a Groovy rule, the rule submits the DataMap execution through the Jobs API on the same secured connection, and the job runs and returns its status. No administrator involvement, no elevated rights, and the user gets confirmation that the data has moved.

It uses the same privilege-in-the-connection pattern as the CLS work, which is the point of building it that way once. The second capability was mostly a matter of pointing the established pattern at a different job type.

Why Cell Level Security, and not something else

We looked at the obvious alternatives before settling on CLS.

Approval process workflow governs how plan data is reviewed and promoted through a hierarchy. It is the right tool for sign-off, but it does not give you a switch that makes an intersection read-only at runtime. Valid Intersections control which member combinations are allowed for data entry, which is a structural rule about validity, not a lock you flip per scenario. Bending either of them into a dynamic lock would have meant using a feature for something it was not built for, which is how implementations accumulate the kind of cleverness nobody can maintain later.

Cell Level Security does the thing directly. It enforces read-only behaviour at the intersection, it takes effect immediately in forms and Smart View, it is granular, and it is defined as rules, which is exactly what makes it controllable from a Groovy script. For a dynamic lock and unlock, it was the right fit rather than the available workaround.

The governance that holds it together

The part security and audit cared about is that nothing here widens user access.

The result is an operation that behaves, from a control standpoint, exactly like an administrator did the work, because under the surface an administrative context did, while the person who triggered it stays inside their normal permissions.

What changed for the client

The visible change is a marked drop in how much finance depends on administrators during close. A lock or unlock used to be an administrator task: raised as a request and, depending on who was free, actioned the same day or the next. Those operations now sit with the Central Finance users who need them, and they take effect immediately when triggered. The administrators who used to field the requests get that time back, and no one’s access was widened to achieve it.

A pattern, not a one-off

What we would take from this to the next engagement is not the specific rules. It is the approach. When finance needs operational control that ordinarily requires admin rights, the answer does not have to be more access. You can put the privilege in a controlled execution path and give users a button instead of a role. That keeps governance intact and still gets the waiting out of the close.