20% of Part II — permission scoping, not just access.
4 tasks · this deck covers task 1 of 4
↑ Administrator Roles OverviewOkta's standard admin roles are broad. When a job only needs a slice of that power, a custom role is how you build exactly that slice.
A role is "a set of permissions that you constrain an admin to." Two types exist: standard and custom. Currently, custom roles are limited to managing user, group, and app activity, plus running profile source imports — broader admin permissions aren't yet supported for custom roles.
Resource sets are only available for custom admin roles — this is the real distinguishing feature. A resource set lets you constrain a role to a specific collection of resources, instead of granting it org-wide reach.
You can build an assignment starting from any of three components: the Admin (user/group), the Role (permission set), or the Resource set (resource collection) — whichever makes sense for how you're thinking about the assignment.
These aren't soft guidelines — plan a scalable role/resource-set naming and structure strategy before you hit them.
Watch for these in your own sandbox run:
→ Trying to grant a custom role permissions beyond user/group/app management + profile source imports — not currently supported.
→ Assuming standard roles can be scoped to a resource set — that's a custom-role-only feature.
Sources: help.okta.com — about-creating-custom-admin-roles.htm
Next: Task 2 →