Hello @ShoichiroK.00155 (LAC Co., Ltd)​  Thank you for posting on our Community page!

If you add a user to an App Assignment group and a Group Push group at the exact same time (such as via a single Group Rule), a race condition will almost certainly occur.

Here is a breakdown of exactly how Okta handles this behind the scenes, why the limitation exists, and how to build around it.

1. The Race Condition Explained

Okta does not have an internal, built-in mechanism that pauses Group Push to wait for user provisioning (App Assignment) to complete.

When a user is added to both groups simultaneously, Okta fires off two independent, asynchronous background tasks:

• Task A (App Assignment): Initiates a SCIM call to create and link the user profile in the downstream application.
• Task B (Group Push): Initiates a SCIM call to update the group membership in the downstream application.

Because these tasks run asynchronously, Task B will often execute before Task A has finished. When the Group Push process attempts to add the user to the downstream group, it looks for the user in the target app. If the provisioning process hasn't finished creating or linking that user yet, the push fails, and you will see a Group Push error in the Okta admin console.

2. If Timing Isn't Fixed, Why Separate the Groups?

You are entirely correct that the primary purpose of separating the groups is to allow administrators to decouple them and explicitly control the execution order.

Furthermore, Okta explicitly mandates this separation in their official documentation, stating: "Okta doesn't support using the same group for app assignment and Group Push." Separating the groups solves an architectural problem rather than a timing problem. If you try to use a single group for both, Okta's database struggles to reconcile the local Okta group membership with the downstream app's group membership during a single sync event, resulting in overlapping API loops and phantom push errors. By separating them, you eliminate the database conflict and lay the groundwork to control the timing yourself.

3. Best Practices for Controlling Execution Order

Because Group Rules fire simultaneously, they are not the best tool for assigning a user to both groups if you want automated, error-free provisioning. To enforce the correct order of operations, consider these operational procedures:

• Okta Workflows (Highly Recommended): This is the cleanest way to solve the race condition. You can build a flow that triggers when a user meets certain criteria:

1. Assign the user to the App Assignment Group.
2. Use a Wait/Pause card, or actively poll the user's application status until it returns as successfully provisioned.
3. Assign the user to the Group Push Group.

• Manual Retry (The "Let It Fail" Approach): If you must use simultaneous Group Rules, you can simply allow the race condition to happen. The user will be successfully provisioned, but their Group Push will throw an error. An administrator can routinely navigate to the application's Push Groups tab and click Retry All Groups to resolve the backlog once provisioning has caught up.
• Staggered Group Rules (Less Reliable): You can base the Group Push rule on an attribute that is only populated after a successful downstream writeback, though this depends entirely on the specific application's SCIM capabilities and is often difficult to perfectly time.

Thank you for reaching out to our Community and have a great day!

--

Help others in the community by liking or hitting Select as Best if this response helped you.