Work with the admin component
As a super admin, you can assign admin permissions to other users so they're able to perform tasks and access resources. You can assign standard roles to an admin, or create custom roles that limit an admin's access to a subset of permissions and resources.
Users and groups with assigned admin roles have access to the Admin Console. They also have access to the permissions resources that are included in the assignment.
Assign admin roles to users and groups
You can assign admin roles to individual users or to groups of users. When you assign admin roles to a group, each of the admins in that group are assigned the role.
You can view the users and groups with assigned admin roles by selecting the tab, and then selecting Users or Groups. You can also view admin role assignments in and in .
Assign admin roles to apps
You can assign admin roles to your org's custom API Service integrations.
You can view the apps with assigned admin roles by selecting the tab, and then selecting Apps. You can also view admin role assignments in .
If you want to automatically assign the super admin role to your custom API service integrations, you can enable this functionality in .
Third-party administrators
Third-party admins perform some administrative actions, but they can't do any of the following things.
-
Receive Okta admin email notifications
-
Contact Okta support
-
Sign in to the Okta Help Center
Third-party admin scenarios
Some organizations need to set up administrator roles in Okta for individuals who perform admin functions but aren't direct employees of their organization. The parent organization may even create a custom portal for administrator functions, so that third-party admins don't even see the Okta interface.
Consider the following scenarios:
- An org's support team outsources its services to a third party. This third party manages user needs on behalf of the org but doesn't actually see the Okta user interface.
- An org uses a business to business to consumer (B2B2C) model. A "hub-and-spoke" is set up with end customers (external users) created as admins so they can run their own Okta org. The org may offer a custom portal created with Okta APIs so these external users aren't aware that they're admins in Okta.
If the external users in these scenarios are given traditional admin roles in Okta, they receive default Okta admin emails like customer notifications, admin email alerts, and welcome messages. By giving these users third-party admin permissions, you can prevent them from receiving Okta admin email notifications, or from contacting Okta support.