Hi - noticed an odd thing in DPM that forced us to revoke our users access and reduce their ability to self service. Wondering how other folks navigate this.
Scenario: the way we planned to use DPM, each member of our 20 person accounting department is an Advanced user in Prophix. Ideally, they would have access to DPM. The security layer in DPM would ensure that they don’t have access to sensitive Attributes. This works well - on the person’s Profile page things like Salary and Medical Aid Package don’t show. We were excited to learn about the cleverness of the DPM security layer.
We wanted to work this way because the person is still able to make changes to non-sensitive attributes, inactivate the person, add/remove pre-set allocation options, add actions, add Input calc factors. Great self service options.
However, in practice if a user clicks on the person’s ‘summary’ it shows an output of all their calculations. It breaks the usefulness of being able to hide sensitive attributes, if the Calculations are then available, because they are of course the final output of DPM and equal to exactly what the person is being paid. In addition, this is mirrored in schedules. If one goes to schedules, you’ll find you cannot add Attributes you do not have access to in a schedule. But, you’ll find you can add any of the Calculations… again defeating the purpose of hiding Attributes.
We have been informed one strategy is to remove DPM access for Advanced users, and then only send them schedules to fill out (or just view and double check) via Workflow, and control the data contained in those schedules. This is a viable 60% work around. It doesn’t solve the following:
- Actions, Allocations, Input Calcs, Deletion and maybe Inactivation (haven’t tried) are not available in schedules.
- IF you want to have an advanced user or non-security administrator (think systems-smart member of the accounting dept) help the “payroll people” with the calculation creating and editing or any trouble shooting in DPM, you cannot prevent that user from having inevitable access to everyone’s private data.
I believe this is likely a feature request, but wanted to understand reactions here before logging if anyone else has come across this.
Is the sensitive information settings turned to “Hidden” on the summary page? This would make it hidden for all users. The data can still calculate and post to the appropriate accounts. This can be accomplished by using the Report Category and put the calculation that shows the sensitive data and move it to the reporting category which is hidden.
You can hide attributes, but this method will also hide the calculation.
1 Like
We use discretionary calculations and then don’t include them in the summary that you are speaking of. You can make sensitive calculations discretionary.
Is this added layer of security for DPM a new feature? If so, I am not aware of it.
We have four accountants who have DPM access to the personnel cube, but these same people also all have access to payroll data.
I would not want my advanced users to go without DPM access.
I think that you need to figure out how you want various advanced users to be able to use DPM and then construct the security levels as such. So, all 20 of your accountants might not have the same access because they are all meant to do something different as part of your personnel planning
1 Like
Hi - thanks both. So i’m going to round this up a bit to see where we are at. First, the advice on hiding sensitive calcs in the Summary is great, really appreciate it. I did so by going to “reporting categories” in DPM and selecting hidden + not shown in summary. This is great because it solves the most likely ‘stumble across it’ piece.
So on to the problem that anyone with DPM access could add any calculation to a schedule and then still see everyone’s sensitive information. This is still a problem. Current solution on offer is to remove direct access to DPM for most users, and instead send them DPM workflow actions. They can then only see the schedules that the “DPM Designers” let’s call them are putting out for them to fill out. Biggest issue with this workaround is lack of self-service access for those members to:
actions, allocations, input calcs, deletion and inactivation of Employees
1 Like
Thanks Emily. I agree with your final statement. What I’ve figured out I want to do is give all my advanced users the ability to fully self service in DPM. The issue is when I then go and attempt to construct the security around it - I can’t, because they inevitably have access to the private salary information of all the Employees in the business units they account for. Let me know if you’re seeing something different!
So, the accountants aren’t supposed to see the salaries of the people that fall into the areas that they account for? Are they supposed to see any salaries at all?
From what you are saying in your post, it seems like payroll inputs salaries and you just want Accountants to adjust some attributes here and there?
The attributes and inputs that you called out cannot be done via a schedule, I agree there and I think that the only way around it is for prophix to add those possibilities into the DPM schedule selections.
You can have many calculations be triggered based on various attributes - think check boxes, lists, true/false. So, perhaps you set those up as flags for the people in payroll who load in the salaries? Example, have a flag noting that someone received a wage allocation. And then have another attribute for payroll to mark that they looked at it and made the adjustment.
We have Personnel DPM Security set up through added layers in our Geography dimension. I’m not sure if it would help this situation though.
1 Like
Emily, can you explain more your geography based security structure?
Here is an example:
Say, two advanced users both roll up under A geography dimension for Administration. Neither user should see each other’s wages nor anyone’s wages above them. I would set it up like this:
001 Administration
0001 Executives
0002 Managers (Prophix Users)
00002 Manager A
00003 Manager B
0004A Manager As Team
0004B Manager Bs Team
In this case, I would give Manager A security access to “00002” and “0004A”.
Manager B would have security access to “00003” and 0004B.
This results in each Manager not being able to see the executives wages above them, the manager at the same level, and the other Managers team.
The Accounring Team member who is assigned as the accountant for specific groups could be granted access to see wages only for those groups.
The Executive level could have access to all wages below them (if you wish).
Does that make sense?
1 Like
Although this is very old, just wanted to update that since this time, the ability to edit essentially everything in DPM via the workflow schedule has been added, which resolves my issues.
You just click on any row in the schedule, then select “edit member properties” i think it is. In a popup, you can edit all the additional complex things that don’t fit easily into the schedule, including allocations, input attributes, etc…
You can also remove records and make records inactive.
1 Like