Support dynamic "Current User" member resolution in Cell parameters for Action Buttons

Dear team,
Summary

Allow Current User to be used as a dynamic member selection when configuring a Cell parameter for a TurboIntegrator process executed from a PAW Action Button.

Currently, Cell-based Action Button parameters require a static member selection for every dimension of the cell intersection. This works well for static scenarios, but it does not support user-dependent use cases.

Current Behaviour

When configuring a process parameter with the Cell control type, the author selects:

• a cube

• one specific member for each dimension of the cell intersection

The resulting cell reference is therefore completely static. For example:

Cube: }Client_Parameter

Dimension       Member
-----------------------------
}Clients        USER_A
Measure         Selected

The Action Button will always use the cell for USER_A, regardless of which TM1 user executes the Action Button.

IBM has confirmed that this is currently the expected behaviour of the Cell control type: it uses a fixed, statically selected cube intersection.

Requested Enhancement

Provide an additional option for a dimension member such as:

Current User

instead of requiring a fixed member.

For example:

Cube: }Client_Parameter

Dimension       Member
-----------------------------
}Clients        Current User
Measure         Selected

At runtime, the Current User member would be resolved to the TM1 user executing the Action Button.

Conceptually, this could resolve in the same way as TM1User():

USER_A → }Clients = USER_A
USER_B → }Clients = USER_B
USER_C → }Clients = USER_C

The same Action Button could therefore dynamically retrieve the appropriate cell value for each user.

The exact technical implementation is open to IBM. The requirement is that the dimension member is resolved dynamically according to the currently authenticated TM1 user.

Example Use Case

A parameter cube contains user-/client-specific settings:

}Client_Parameter

             Selected
USER_A          ...
USER_B          ...
USER_C          ...

A PAW Book contains one Action Button that executes a TurboIntegrator process.

Instead of configuring a separate Action Button or additional logic for every user, the Cell parameter could use:

}Clients = Current User

The same Action Button would then automatically use the value belonging to the user who is currently logged in.

The user-/client-related dimension does not necessarily have to be the system }Clients dimension. The same concept would be useful for any dimension containing user- or client-specific members.

This pattern is common in multi-client and multi-user Planning Analytics applications where parameter cubes store user- or client-specific settings.

Benefits

This enhancement would make Cell-based Action Button parameters much more useful for multi-user applications.

Potential use cases include:

• User-/client-specific parameter cubes

• User-specific settings and selections

• User-specific workflow actions

• Processes requiring a client or user parameter

• Applications where the same Action Button should behave differently depending on the logged-in user

It would reduce or eliminate the need for:

• separate Action Buttons for different users

• hard-coded user/client members

• additional TI logic solely to determine the current user

• additional workarounds to pass the current user into the process

Security and User Context

The Current User value must always be resolved from the authenticated PAW/TM1 session context.

It should not be possible for the user executing the Action Button to supply or override the user value through the Action Button configuration or process parameters.

This ensures that the dynamic member selection always represents the actual authenticated TM1 user.

Member Existence and Error Handling

If the currently logged-in user does not exist as a member in the selected user-/client-related dimension, PAW should provide a clear and actionable error message.

There should be no silent fallback to another member or value.

Backward Compatibility

Existing Cell-based Action Button configurations using static members must continue to work unchanged.

Current User should be provided as an additional optional selection rather than changing the behaviour of existing static Cell parameters.

Related Functionality

This request is related to the existing Action Button / Control Object functionality, including the use of the }Clients dimension with Action Buttons.

There has also been discussion in the IBM Planning Analytics community around passing the user who started an Action Button process, equivalent to TM1USER().

This would bring Cell parameters closer to the existing TM1User() functionality already available inside TurboIntegrator processes, while keeping user resolution directly within the Action Button configuration.

Expected Behaviour

The Cell parameter configuration should provide an option to define a dimension member dynamically as Current User.

For example:

Control Type: Cell

Cube:         }Client_Parameter

Dimension     Member
-----------------------------
}Clients      Current User
Measure       Selected

At runtime:

Logged-in user     Resolved member
-----------------------------------
USER_A              USER_A
USER_B              USER_B
USER_C              USER_C

The same Action Button configuration should therefore work for all users while dynamically retrieving the cell value belonging to the currently authenticated user.

Environment / Scope

This request applies to Planning Analytics Workspace Books and Action Buttons using the Cell control type to supply parameters to TurboIntegrator processes.

The current static Cell behaviour is documented by IBM as the existing design: the author selects a cube and the members defining the cell intersection.

The requested functionality would be an extension of the existing Cell control type rather than a new Action Button mechanism.

Thanks in advance.

With best regards,
Vitalij