How to configure SCIM Group Push without breaking app roles
SCIM provisioning gets users into an app. Group Push can also send group names and memberships downstream. That is useful, but it is also where role mapping gets messy if the app treats a group name as a permanent permission model. The safe design is simple: Okta can push and rename groups, but the app should map permissions by stable internal IDs and explicit role assignment.
Group Push is not the same as app assignment
Okta recommends separating the group used to assign users to an app from the group used for Group Push. The assignment group controls who gets the application. The push group controls downstream group membership in the target app. Reusing the same group for both jobs can create confusing provisioning behavior.
A practical pattern is to create one group for app assignment and one or more groups for downstream roles or access containers. Assign the app with the assignment group, then use the Push Groups tab to push specific role or access groups to the app.
Know what Group Push does
Group Push sends Okta groups and memberships to a provisioning-enabled app. The pushed group is managed from Okta, and changes made directly in the downstream app can cause synchronization issues. If the downstream app already has a matching group, Group Linking can connect the Okta group to that existing app group.
That means group ownership matters. If Okta owns the pushed group, treat Okta as the source for that membership. If the app owns role assignment, treat the pushed group as an input that an app admin maps to the correct role.
Be careful with rename behavior
When using Group Linking, Okta can rename app groups to match the Okta group name. That can be convenient, but it can also surprise teams if an application depends on the visible group name. The safer application design is to use a stable group or role ID internally and treat the display name as editable.
For Atomation, a pushed group can be created and renamed from Okta, but role permission should not depend on the display name alone. The group receives a stable internal identity, and an Atomation admin can map it to the correct standard or custom role. New pushed groups can start with a safe default role until an admin changes the mapping.
Map groups to roles deliberately
Do not assume every Okta group name should become an admin role. A group called "IAM Admin" might mean full application administration in one company and read-only IAM review in another. A group called "SOC 2 Reviewers" might need report access but no settings access. Group names carry business intent, not a universal permission model.
The app should let an administrator review the pushed group, choose the app role, and change that mapping later. That protects both sides: Okta can manage membership, while the app keeps authorization explicit and auditable.
Import and link groups when needed
Some workflows start from groups that already exist in the app. In that case, Okta can import groups from the provisioning-enabled app, then use Group Linking to connect an Okta group to an existing app group. Okta's import flow can scan for new users, groups, and profile changes after a successful import.
This matters during migrations. If a customer already has app roles or groups, linking is usually safer than creating duplicates. Refresh the app groups, review the imported names, and decide whether to link or create.
Common mistakes
The most common mistake is using one group for app assignment and Group Push. The next is treating group display names as the source of authorization forever. The third is allowing direct downstream edits to a group that Okta is supposed to own, which creates sync conflict and confusion.
Another mistake is skipping the app-side role review. SCIM can move identity data, but it cannot know your application's least-privilege model unless the app gives admins a place to map groups to roles.
How Atomation handles it
Atomation supports SCIM user provisioning and Okta pushed groups. A pushed group can be created, renamed, and deleted through the SCIM flow. The group identity stays stable even if the display name changes, and workspace admins can map groups to Atomation roles instead of relying on a brittle name match.
Use Okta for identity synchronization and the app for explicit authorization. Atomation's SSO and SCIM docs follow that model. Assessment scan tokens request only the 31 approved read scopes and do not auto-remediate; the permanent connector's Super Administrator role and org-level maintenance grant are disclosed separately. Explore the demo: demo.atomation.io.