Building a custom role

The requirement is the common one: a delivered role is close, but it grants one thing it should not. Copy the delivered role — and understand the difference between a top-level copy and a copy with inheritance, because the consequence of each is different and changing your mind afterwards is expensive. Remove the offending duty role, add one from elsewhere, save, regenerate, assign, and test by signing in as the user. Never assume a role does what its name says. Every custom role is a permanent maintenance liability. Create as few as you can. Delivered roles gain capability at each release and copies do not, so every copy you create is something to review at every upgrade, forever. Then document it: role name, why it exists, what it was copied from, who approved it. The lesson shows the register you would keep. Once you have gone, that register is all…

In this module: Module 2 · Security and User Provisioning

1. 1The security mental model
2. 2Function vs. data security
3. 3The role types
4. 4Provisioning your first users
5. 5Data access: ledgers, business units, asset books
6. 6Building a custom role
7. 7Segregation of duties
8. 8What breaks
9. 9Lab: provision a finance team