Data Cell Access Security

Hi hoaphan​, as many as are needed to accommodate your Security requirements.  You can get as granular as the base members of any dimension if needed, but hopefully you don't need to get to that level.  To limit the groups make sure you are leveraging Entity and WF security appropriately and do those first for Read/Write, and WFA/WFE, then go to Data Access Security as a step after your baseline Security model is established.

Yes, as MikeG​ mentioned, as many as you want but you have to balance performance.  The more slices you have, the more OneStream has to think through cell combinations to determine data access.  So definitely try to limit slice and use "STOP" in evaluation order when possible.

Thank you for your valuable support, T_Kress​ and MikeG​ .

I plan to implement plural Data Cell Conditional statements to effectively mimic the functionality of the noinput business rule.

Leveraging data access is essential for mitigating performance issues, particularly since each time OneStream opens a cube view, it activates the execution of the noinput business rule. As you mentioned, I need to be cautious with data access to maintain optimal performance.

However, if I find myself with no other options, what strategies or best practices can I employ to address the performance challenges associated with the noinput business rule?