User List Top Level

AWhitworth

The users' list should have a top-level for calculations. Currently, the users' list can't be used for inputting data as there is no top-level so errors occur when referenced by a line item without the user dimension.

 

 

DavidSmith

@AWhitworth 

 

Hi

Could you describe the use case?  Why do you need the aggregated values from a module by user?

Cheers

David

obriegr

@Awhitworth

Whenever I have run into this issue, either A) I am using the user list incorrectly or I create a new list in the model that is a 'dummy' list that has a 1 to 1 relationship with the actual users list. I think link the 2 through a properties line item (in a module) and use that as my point of reference.

When I do have a dummy list, usually bringing the top level information doesn't result in what I had expected and revealed how I was using the user list incorrectly through a little investigation.

To iterate on @DavidSmith's inquiry, what is your use case? This drastically changes how I would approach the problem.

AWhitworth

Thanks both,

 

A dummy mapped list is the workaround implemented and I can see why it would be a better solution in a lot of cases. This particular use case is a really simple time entry module where users log into Anaplan and enter their monthly timesheet against activity codes. The outputs of this are then passed to a budgeting model and used for allocating costs etc. As this is going to be a fairly large number of users and can change regularly (monthly) but the actual user attributes aren't particularly important for the later modelling it seemed much simpler to use the users as a dimension instead of a second list.

 

Do you have any suggestions of how we could cut down the admin burden of operating a second parallel users list? 

Miran

Status changed to: In Review

DavidSmith

Thanks for the use case - It's helpful for me as I validate the difference uses and requests

 

This is what I've done in the past, assuming you are not importing users from a central model

1. Create a module dimensioned by Users and use as an import source to import to a dummy list of users

2. Have a clean up module dimensioned by the dummy list of users, that flags any dummy users that are not in the main users list

3. Run the delete from list action

 

David

alexpavel

@AWhitworth

 

You have a point: the "Users" list does not behave as the "normal lists" when trying to use SUM function to calculate the Total of the list, even there is not "Total" element setup in the normal list. 

 

When you try this with "Users" list you will always receive the above error or something like  "Invalid use of 'Users' list with function 'SUM'".

 

However, I would always avoid using the "Users" list in an input module in order to have saved input data by the users, especially for longer-term important historical data. 

 

The "Users" list is quite volatile and the elements of the list are physically deleted when a user is setup with "No access" and all the historical data related to that user would be lost.  

 

I would use the "Users" list only for temporary and not important for historical saved data input modules or for filters modules.

I think the main reason that "Users" list was created was for filtering functionalities.. 🙂

 

If you need to save data for a longer time, I would use the @DavidSmith suggestion and create the "dummy users" list using as the starting point the "Users" list...

Using "Dummy users" you will have control to delete elements and not lose historical data even it will add some additional admin tasks in order to maintain the "dummy users" list. 

 

Best!

 

DavidSmith

Status changed to: In Review