Freeze Access at direct Report Level

Hi Colleagues, I'm currently facing the following dilemma, hoping I can get some guidance from you: 

We have a freeze module driver that locks all direct reports of a Manager like this:

Module X (applies to Users, line items)

Line item 1: Manager (format: users)

Line item 2: Freeze/Unfreeze input - Boolean

Line item 3: Read role - Line item 2 [lookup: Line item 1]

 

It is working just fine, but now the requirement is to lock individual employees rather than in bulk. It's important that when displayed in app, to show only direct reports and not entire user base. Also, looking forward of achieving this without creating a list with users that must be updated constantly. 

Best Answer

  • ryan_kohn
    Answer ✓

    I'll reiterate that your current configuration that stores the relationship between employees using the Users list directly is going to be limiting, and this is what you are running into now. It sounds like what you want to do is apply a simple filter based on the Current User; however, you need the Users list on the page context in order to make this work, while also needing the Users list on rows to manage the data -- and you can't have the Users list as a dimension twice.

     

    You could feasibly accomplish what you are looking to do by replicating the Users list into a "fake users" (or "dummy users") list.

     

    Per your initial post, you should have a module that looks something like this, where you have a mapping of users to their direct manager:

    ryan_kohn_0-1649705015316.png

     

    After replicating the Users list into a Fake Users list, you can set up a module that contains the mapping of Fake Users to their "real" user manager:

    ryan_kohn_1-1649705182852.png

     

    And then you can set up a module where you can pivot your Fake Users against your real Users:

    ryan_kohn_2-1649705259563.png

     

    Once this is in place, you can set up a grid card on a page to use the Current User filter to only show a manager's direct reports:

    ryan_kohn_3-1649705348235.png

     

    Finally, you can expand your initial module to find the result of the direct report-level 'Freeze Forecast?' value and map it back to the regular Users list, which you can ultimately use in your read/write drivers for forecast input capabilities.

    ryan_kohn_4-1649705932351.png

     

Answers

  • If I'm understanding correctly, you're looking to be able to override the freeze/unfreeze capability at a lower level of the hiearchy. I'd recommend reviewing this microlesson from Level 2 Model Building: How to Adjust or Override a Previously Calculated Value.

     

    Additionally, I would recommend rethinking how you have your employee hierarchy structured. Storing the manager-report relationships using the Users list will probably cause problems down the line when you have employees leave the organization, change roles internally, get promoted, etc. It's more sustainable to build these relationships into a hierarchy using lists so that you can effective-date any changes, and also maintain data if you need to remove individual users from the model.

  • Hi Ryan, long story short, we need to get managers the possibility to lock individual direct reports (employees) - freeze data input in a forecast module. Currently we store manager details in a system module and don't use any other employee hierarchy besides 'Users'. 

     

    Currently, based on the setup I shared, a manager can lock the data for input but for all direct reports. Now the requirement is to show all direct employees in the dashboard, but lock them individually. I want to achieve this, without displaying entire 'Users' database in the dashboard. 

  • Thanks Ryan, this was really helpful, appreciate all the guidelines. A similar approach I was thinking - as you said, the only way I could filter was to have users as a page selectors and another dummy users list.

     

    Which is what I tried to avoid, creating another dummy list that ultimately needs constant maintenance every time new users are added in the model.  But it seems this is the only feasible solution, so I will go ahead with this proposal for our needs. Thanks once again for the solution provided.