Security

Hello!

Our security framework was set up by our implementation consultants so unfortunately I can't point you in the direction of any documentation. I can say that yes, we use nested security groups often.

For example, we have an entity read security group (which is assigned to the entity in the dimension library) and a child of that group would be our actuals execute workflow security group. Similarly, we have a scenario read (or write) security group and a child of that group would be the forecast or actuals execute workflow security group. Hopefully that makes sense. 

It could definitely become messy depending on how many layers and what you need security around but once you outline it and replicate it for all workflows/subs/entities/scenarios/etc, it's a little easier to manage. 

Hi,

Similar to other systems the best practice is to create groups of the highest granularity to cover every use case of where the security needs to be locked down to a particular user(s). Keeping in mind to future-proof in case you think there will be further granularity required down the track. In many ways OneStream makes it easier than other platforms as I find the security more easily visible (e.g. workflow access, workflow execution access groups are visible at the top of each workflow and by scenario). Metadata access is also visible just beneath the name of the workflow in the Dimensions screen.

Nesting of groups is advised, for example if a workflow is to be accessed by Process_A_Users and Process_B_Users then you would set up a parent group e.g. Process_A_and_B_Users, assign both the other groups as children of this group, and assign the parent group to the workflow.

Cheers

The Design and Reference Guide has content on Security and some of the best practices

Platform Guides > Design and Reference > Foundation Guides > Security Best Practices

There is also the the OneStream Foundation Handbook.