---
title: Known issues and limitations
description: When create, read, update, or delete operations are performed on an LDAP user, most changes propagate to Google within minutes. However, changes can sometimes take up to 24 hours to propagate. For more information, see How changes propagate to Google services.
component: google
page_id: google:google_workspace_provisioner:pf_google_workforce_connector_known_issues_and_limitations
canonical_url: https://docs.pingidentity.com/integrations/google/google_workspace_provisioner/pf_google_workforce_connector_known_issues_and_limitations.html
llms_txt: https://docs.pingidentity.com/integrations/google/llms.txt
docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md
revdate: July 23, 2024
---

# Known issues and limitations

* When create, read, update, or delete operations are performed on an LDAP user, most changes propagate to Google within minutes. However, changes can sometimes take up to 24 hours to propagate. For more information, see [How changes propagate to Google services](https://support.google.com/a/answer/7514107).

* When the `onDisable` or `onUpdate` property's value is changed from false to true for an LDAP user, changes won't propagate to the target unless a new update is made to the user.

  |   |                                                                                                                                                                                                         |
  | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  |   | The `onDisable` property doesn't disable LDAP users at the target when set to false. Neither does the `onUpdate` property update LDAP users at the target when set to false. This behavior is expected. |

* You can only edit the `isAdmin` property through the `users.makeAdmin` method. Edits made to the `isAdmin` property through the `users.insert` or `users.update` methods are ignored by the Google API service. Learn more in [Make a user an administrator](https://developers.google.com/admin-sdk/directory/v1/guides/manage-users?authuser=2#make_admin/) in the Google developer documentation.

* User attributes cannot be cleared once set.

* When an LDAP user is deleted in a targeted group distinguished name (DN), the provisioning connector does not propagate the deletion until a new user is added to the group. This limitation is compounded when the **User Create** provisioning option is disabled. You can find solutions [SaaS provisioner does not remove the user](https://support.pingidentity.com/s/article/After-deleting-an-AD-user-account-SaaS-provisioner-does-not-remove-the-user-in-the-next-provisioning-cycle-when-Group-DN-is-specified) in the Ping Identity Knowledge Base.

* Google does not properly handle creating users with an invalid `addressCountry` value.

* The Connector sends the value of work for the Organization type but Google does not retain this value and as a result the Organization type has no value.

* Google treats certain user attributes as complex data sets: Address (address\* attributes), organization (org\* attributes), and phone (work\* attributes). Any unmapped or empty fields within a complex data set will be cleared in the corresponding Google account.

* The Password Manager requires PingFederate 9.3 or later if deploying it within PingFederate.

* Nested group membership cannot be preserved. The Google Workspace Provisioner can provision all of the nested groups to Google Workspace when **Nested Search** is selected in the channel settings, but can't maintain the nested hierarchy. Learn more in [Specifying a source location](https://docs.pingidentity.com/pingfederate/latest/administrators_reference_guide/help_saaschanneltasklet_saassourcelocationstate.html).