Adding a user-specific selection to a calculation without using the User list?

ADenchev

Hello, i am trying to find a solution to the following user story:

 

There are a set of modules for a reporting page that currently consist of multiple dimensions (we cannot use a combined list of only possible combinations due to the users not liking the loss of flexibility). These modules return a calculation that needs to be affected by four user-driven booleans that change the underlying calculation.

The current setup's problem is the booleans are not user-specific and thus if one user makes a boolean selection to change the calculation, this will affect another user's work due to the numbers changing. If we want the calculations to be user-specifically changed, we need to add the user dimension to the modules (which will result in a massive explosion of space consumption which we cannot afford).

 

Is there a way we can make the booleans user-specific without exploding the model, without changing the current dimensionality of the modules to a combined list, etc? I've thought about replicating the KPIs in a separate module (that will work as a LISS) that has every possible combination of the tickboxes used, and to filter the metric we want to show based on the tickbox selection, but this has a similar space increase, so it's not a viable solution.

 

Thank you very much for the help in advance!

 

Best,
Alex  

ADenchev

Hi @ChrisAHeathcote, thank you for your response!

The example you give is close to what i imagined - having all combinations of the selections, then make the user's choice filter what KPI we use in the front-end (if i understand your proposal correctly). This will not work in our case as it will create almost the same sparsity as incorporating the user dimension in the calculations.

 

If we cause the filtration to adjust the user's items in the UI view, indeed the summary levels will not work properly, and this is one of the key benefits our superusers praise the most in the report(s).

Which brings me to the answer for your last question - you are absolutely right that a series of combination lists as core dimensionality for the module setup will be beneficial, and can solve the same user stories the same way as separate lists, however the model is already live (i wasn't the original builder, thus i cannot say why the original builder hasn't chosen this method) and reworking it to this approach requires resources that cannot be spared at this time.

 

Best,

Alex