Reading the security console

The security console answers a question no design document can: what does this user actually hold today, as opposed to what somebody intended to grant them. Two views matter. From the user, you can see every role assigned and expand each into its duties and privileges — which is how you find the privilege arriving through a role nobody remembers assigning. From the role, you can see every user who holds it, which is the direction an audit question always comes from. "WHO CAN POST A JOURNAL?" IS A REAL QUESTION AND IT HAS A REAL ANSWER. Start from the privilege, walk up to the duty roles that carry it, then to the job roles that carry those, then to the users holding them. The answer is usually longer than anybody expects, and the surprises are almost always inherited — somebody holds a broad role for one feature it contains…

In this module: Module 2 · Security, roles and what you are allowed to see

1. 1Roles, privileges and duties
2. 2Data security versus function security
3. 3Data access sets and business unit security
4. 4The security diagnostic sequenceFree preview
5. 5Reading the security console
6. 6Security for reporting: the part people miss
7. 7Custom roles: when, and how to survive an update
8. 8Provisioning and role assignment at scale
9. 9What breaks: the three security failures you will meet
10. 10Lab briefing · Diagnosing three access failures