0D5WR000029AzAT0A0Okta Classic EngineAdministrationAnswered2026-09-18T15:31:24.000Z2026-09-17T11:55:20.000Z2026-09-18T15:31:24.000Z

SurajB.69263 (Customer) asked a question.

September 17, 2026 at 11:55 AM

understanding SYNC behavior for Org units (Okta <-> Google)

Thanks for the very detailed response! earlier case here is the previous case (https://support.okta.com/help/s/question/0D5WR000026zdd60AA/understanding-sync-behavior-for-org-units-okta-google?language=en_US), However This does not match what we see in Okta / Google. Im betting some of this is based on when the Okta / Google integration was configured but our ultimate goal is to be able to manage the OU’s in Google without Okta overwriting it and have Okta just provision access and handle push groups as needed.

 

When we look in Okta under the provisioning settings here is what we see. This looks to contradict your note above. The attribute for the bidrectional sync is set to / (and my understanding is that means the top level OU in Google)

 

However notice the sceenshot of the end user, it has the / denoted in here app variables but in Google Admin she is in a differnt OU and has been there for much longer than 12 hours.

the image are in the link as not bale to add the image https://drive.google.com/drive/folders/1wfBIc6HiF7Ptm15m1nTBxTEEBg0UuURN

 

 

  • 1 answer
  • 22 views

  • Paul S. (Okta, Inc.)

    Hello @SurajB.69263 (Customer)​ Thank you for posting on our Community page!

     

    The issue is that the "/" attribute in your provisioning settings is likely a default or fallback value, not an active inbound sync from Google Workspace. Even though Okta supports bidirectional attribute mapping in the Profile Editor, the presence of a mapping does not guarantee that profile import is actively running or that it is correctly pulling the OU attribute from Google Workspace back into Okta.

    Root Cause:

    Okta's provisioning model has two separate mechanisms:

    1. Outbound provisioning (Okta → Google Workspace): Okta pushes attributes from Okta user profiles to Google Workspace. This is enabled by default and runs on a schedule or manually.
    2. Inbound profile import (Google Workspace → Okta): Okta periodically reads user attributes from Google Workspace and updates Okta's user profiles. This is not enabled by default and must be explicitly configured. Even when configured, it runs on a separate schedule from outbound provisioning.

    The "/" value you see in the app variables is likely the default or initial value that was set when the user was first provisioned to Google Workspace. If inbound profile import is not actively running, or if it is not configured to prioritize Google Workspace as the source for the OU attribute, Okta will not pull the user's current OU from Google Workspace back into Okta's profile.

    Solution:

    To manage OUs in Google Workspace and have Okta reflect those changes, you must verify and configure inbound profile import:

    1. Verify profile import is enabled. Navigate to the Google Workspace app in Okta, go to Provisioning → Settings, and confirm that Import New Users and Update Existing Users (or similar language for profile import) is enabled. If this option is not visible or is disabled, profile import is not active.
    2. Check the attribute mapping in Profile Editor. Go to Directory → Profile Editor, select the Google Workspace app profile, and verify that the OU attribute (typically orgUnitPath
    3. in Google Workspace) is mapped to an Okta user attribute. If the mapping shows "/" as a static value rather than a dynamic mapping, it will not pull live data from Google Workspace.
    4. Set profile source priority. Navigate to Directory → Profile Sources and verify the order of sources. If Google Workspace is not listed, or if it is listed below other sources (such as Active Directory), Okta may not prioritize Google Workspace updates for the OU attribute. Reorder the sources so that Google Workspace is the authoritative source for the OU attribute.
    5. Understand the import schedule. Profile import runs on a separate schedule from outbound provisioning—typically every few hours. Changes made in Google Workspace will not appear in Okta immediately; they will be reflected after the next import cycle.
    6. Manually trigger an import (if available). Some Okta app integrations allow manual import triggers. Check the Provisioning → Settings tab for an Import Now or Sync Now button. If available, click it to immediately pull the current state from Google Workspace.
    7. Contact Okta Support for account-specific verification. If profile import is enabled but the OU attribute is still not updating from Google Workspace, or if the "/" value persists despite changes in Google Workspace, this may indicate a configuration issue specific to your setup. Okta Support can verify your provisioning configuration, confirm that profile import is working correctly, and troubleshoot why the OU attribute is not being imported.

    Important: The behavior you are observing—where the app variables show "/" but the user is in a different OU in Google Workspace—suggests that inbound profile import may not be actively pulling the OU attribute. Verify the steps above, and if the issue persists, escalate to Okta Support for account-specific troubleshooting.

     

    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.

    Expand Post
    Selected as Best

  • Paul S. (Okta, Inc.)

    Hello @SurajB.69263 (Customer)​ Thank you for posting on our Community page!

     

    The issue is that the "/" attribute in your provisioning settings is likely a default or fallback value, not an active inbound sync from Google Workspace. Even though Okta supports bidirectional attribute mapping in the Profile Editor, the presence of a mapping does not guarantee that profile import is actively running or that it is correctly pulling the OU attribute from Google Workspace back into Okta.

    Root Cause:

    Okta's provisioning model has two separate mechanisms:

    1. Outbound provisioning (Okta → Google Workspace): Okta pushes attributes from Okta user profiles to Google Workspace. This is enabled by default and runs on a schedule or manually.
    2. Inbound profile import (Google Workspace → Okta): Okta periodically reads user attributes from Google Workspace and updates Okta's user profiles. This is not enabled by default and must be explicitly configured. Even when configured, it runs on a separate schedule from outbound provisioning.

    The "/" value you see in the app variables is likely the default or initial value that was set when the user was first provisioned to Google Workspace. If inbound profile import is not actively running, or if it is not configured to prioritize Google Workspace as the source for the OU attribute, Okta will not pull the user's current OU from Google Workspace back into Okta's profile.

    Solution:

    To manage OUs in Google Workspace and have Okta reflect those changes, you must verify and configure inbound profile import:

    1. Verify profile import is enabled. Navigate to the Google Workspace app in Okta, go to Provisioning → Settings, and confirm that Import New Users and Update Existing Users (or similar language for profile import) is enabled. If this option is not visible or is disabled, profile import is not active.
    2. Check the attribute mapping in Profile Editor. Go to Directory → Profile Editor, select the Google Workspace app profile, and verify that the OU attribute (typically orgUnitPath
    3. in Google Workspace) is mapped to an Okta user attribute. If the mapping shows "/" as a static value rather than a dynamic mapping, it will not pull live data from Google Workspace.
    4. Set profile source priority. Navigate to Directory → Profile Sources and verify the order of sources. If Google Workspace is not listed, or if it is listed below other sources (such as Active Directory), Okta may not prioritize Google Workspace updates for the OU attribute. Reorder the sources so that Google Workspace is the authoritative source for the OU attribute.
    5. Understand the import schedule. Profile import runs on a separate schedule from outbound provisioning—typically every few hours. Changes made in Google Workspace will not appear in Okta immediately; they will be reflected after the next import cycle.
    6. Manually trigger an import (if available). Some Okta app integrations allow manual import triggers. Check the Provisioning → Settings tab for an Import Now or Sync Now button. If available, click it to immediately pull the current state from Google Workspace.
    7. Contact Okta Support for account-specific verification. If profile import is enabled but the OU attribute is still not updating from Google Workspace, or if the "/" value persists despite changes in Google Workspace, this may indicate a configuration issue specific to your setup. Okta Support can verify your provisioning configuration, confirm that profile import is working correctly, and troubleshoot why the OU attribute is not being imported.

    Important: The behavior you are observing—where the app variables show "/" but the user is in a different OU in Google Workspace—suggests that inbound profile import may not be actively pulling the OU attribute. Verify the steps above, and if the issue persists, escalate to Okta Support for account-specific troubleshooting.

     

    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.

    Expand Post
    Selected as Best

Recommended content

No recommended content found...