The security model

Conceptintermediate

Role-based access where job, abstract and duty roles decide what a user can do, data roles with security profiles decide what data they can see, and where the configuration lives depends on the phase: a functional area task list during implementation, the Security Console afterwards.

The confusions are the difficulty. Each one is a belief that sounds right and is not.

  • That security is configured in one place. During implementation the tasks sit in a functional area task list; afterwards most sit on the Security Console, and the exceptions are named where they apply.
  • That a role hierarchy change takes effect on its own. The data security policies of data and abstract roles must be regenerated when the hierarchy changes.

Name the two halves of the security model, say where security tasks live during implementation and after, and state what must be regenerated when the role hierarchy changes.

The functional half is job, abstract and duty roles, deciding what a user can do. The data half is HCM data roles with security profiles, deciding what data they can see. During implementation the tasks sit in a functional area task list or implementation project; afterwards most sit on the Security Console, with exceptions named where they apply. When the role hierarchy changes, the data security policies of data and abstract roles must be regenerated.

Memory hook: Can do versus can see. Task list before, console after. Regenerate when the hierarchy moves.

Rests on SEC-HCM-001, SEC-HCM-003, SEC-HCM-005, SEC-HCM-006.