# Upgrade user accounts on devices Upgrading a user account on a device involves migrating it from a managed Google Play Account to a **managed Google Account**. This process shifts the user's identity from a device-centric, non-personal account to their corporate Google identity, which is the foundation for a more integrated user experience across all Google services. ## Overview The primary goal of this upgrade is to provide customers with enhanced features, such as improved user management through the Google Admin console, stronger security, and access to Google services and AI capabilities like Gemini. ### Key benefits of upgrading user accounts: - **Works with all Google services:** Unlike managed Google Play Accounts, this new identity works seamlessly with all Google services, including Google Drive, Docs, and Meet. It also supports device backup when enabled by the IT admin. - **Seamless user experience:** Through single sign-on (SSO) integration, users are automatically signed in to their corporate environment and all their Google services, such as Gmail. - **Direct identity control:** The organization can directly control the identity lifecycle through manual, automated, or sync-based methods. - **Familiar user identifier:** For better visibility, the new account uses the same email address that the user already knows and uses. ## Prerequisites 1. The customer's Google Workspace Domain must be [domain verified](https://support.google.com/a/answer/60216). It simplifies user management for the IT admin and also allows them to sync directory. 2. Managed Google Accounts for each of the users in the intended account upgrade must exist prior within the admin console. ## API changes This section outlines the key API changes within the policy and non-compliance flow to support user upgrade. User upgrade adds a new field within `enterprises.policies`, and adds new enums in `enterprises.devices` to support new non-compliance reasons. - New fields and enums in the policy [`workAccountSetupConfig`](https://developers.google.com/android/management/reference/rest/v1/enterprises.policies#workaccountsetupconfig). - New enums added to [`specificNonComplianceReason`](https://developers.google.com/android/management/reference/rest/v1/enterprises.devices#specificnoncompliancereason). ## Account upgrade process To upgrade an account, an IT admin updates a device's policy to require a **managed Google Account** for authentication. This is done using the `workAccountSetupConfig` and setting the authentication type to `GOOGLE_AUTHENTICATED`. The optional `requiredAccountEmail` parameter allows the IT admin to specify the exact account the user must use to successfully complete the setup. Depending on the configuration and whether the required account already exists on the device, the user will be prompted to add either a specific managed Google Account or any valid managed Google Account or the upgrade happens automatically in the background. Upon completion, the new managed Google Account becomes the primary one for device management, replacing the old managed Google Play Account. ### New non-Compliance reasons New non-compliance reasons have been added to allow the IT admin to trigger policy enforcement based on different scenarios encountered during the user's login. - If the account entered by the user does not match the `requiredAccountEmail`, an error message is immediately shown on the screen. - If the IT admin accidentally specifies a required email address that is not part of the enterprise domain, the non-compliance reason `REQUIRED_ACCOUNT_NOT_IN_ENTERPRISE` is returned. - If no `requiredAccountEmail` is specified and the user tries to enter an account which is not part of the enterprise, the non-compliance reason `NEW_ACCOUNT_NOT_IN_ENTERPRISE` is returned. ## User upgrade scenarios These user journeys illustrate common scenarios and outcomes when implementing and using the user upgrade feature. They cover experiences from both the IT admin and end-user perspectives. All scenarios assume the device is initially enrolled with a managed Google Play Account. We recommend that you familiarize yourself with these journeys to better support your customers and validate them with your solution. ### Successful upgrade with a specific managed Google Account required When a device's policy is configured with `authenticationType` set to `GOOGLE_AUTHENTICATED` and a specific `requiredAccountEmail`, the user is prompted to add that managed Google Account. After the user logs in, the device syncs the new policy and becomes compliant. As a result, the old managed Google Play enterprise account is removed, and the device is now primarily managed by the specified managed Google Account. ### Successful upgrade with no specific managed Google Account required When a device's policy is configured with `authenticationType` set to `GOOGLE_AUTHENTICATED` but does not specify a `requiredAccountEmail`, the user is prompted to add a managed Google Account. The Google login screen does not pre-populate an account, so the user adds any valid managed Google Account for their enterprise. The device then becomes compliant, managed by the new managed Google Account. As a result, the old managed Google Play enterprise account is removed, and the device is now primarily managed by the specified managed Google Account. ### Silent upgrade when required managed Google Account already exists If a device's policy is configured with `authenticationType` set to `GOOGLE_AUTHENTICATED` and a specific `requiredAccountEmail`, and that specified managed Google Account already exists on the device, the upgrade occurs silently without the user being prompted. The managed Google Play enterprise account is removed, and the pre-existing managed Google Account becomes the primary account for the device's management. ### Prompted upgrade with user selection (pre-existing account, no specific account required) When a device's policy is configured with `authenticationType` set to `GOOGLE_AUTHENTICATED` without a specific `requiredAccountEmail`, and a valid managed Google Account already exists on the device, Android Device Policy will prompt the user to select or add an account. The user may be presented with an account picker and must select or add the chosen managed Google Account, as this is not a silent upgrade. The device then becomes compliant, with the selected managed Google Account serving as the primary account for the device's management. ### Upgrade triggered immediately post-enrollment When a device's policy is configured with `authenticationType` as `GOOGLE_AUTHENTICATED` and a `requiredAccountEmail` before enrollment, it initially gets a managed Google Play Account. Immediately after enrollment, Android Device Policy prompts the user to add the required managed Google Account. The user adds the account through a Google login screen, causing the device to sync, become compliant, and remove the managed Google Play Account. ## Policy enforcement and compliance Android Device Policy includes built-in compliance actions that help guide users through required upgrades and other policy updates. These actions also provide IT administrators with the tools to manage remediation for non-compliant devices. ### Non-compliance leading to device block or wipe When a device's policy requires a managed Google Account (for example, with `authenticationType` as `GOOGLE_AUTHENTICATED` and a `requiredAccountEmail`) and is also configured with `policyEnforcementRules` that specify a block or wipe, Android Device Policy will display warnings if the user remains non-compliant. If non-compliance persists beyond the set days for a block, device usage is blocked. If it persists beyond the days for a wipe, the device is factory reset. This is similar to the existing non-compliance flow. ### Attempted Sign-In with an Unauthorized Account (blocked at login) If a device policy requires a specific managed Google Account using `requiredAccountEmail`, but the user attempts to sign in with a different managed Google Account, an error message is displayed directly on the Google login screen. This prevents the unauthorized sign-in. An example message is, "Work policy requires the specified work account." ### Attempted sign-in with an account outside the enterprise (account removed) When a device's policy requires a managed Google Account but no `requiredAccountEmail` is set, and the user signs in with an account that is not part of the EMM-linked enterprise, the unauthorized account is automatically removed. The user is then prompted to sign in again with a valid account. The device status report reflects a `nonComplianceReason` of `USER_ACTION` and a specific reason of `NEW_ACCOUNT_NOT_IN_ENTERPRISE`. ### Admin misconfiguration: required account not part of enterprise If an admin misconfigures the policy by setting a `requiredAccountEmail` that is not part of the enterprise, Android Device Policy will display an error message, possibly titled "Contact IT admin." The device will remain non-compliant, and the device status report reflects a `nonComplianceReason` of `USER_ACTION` with the specific reason `REQUIRED_ACCOUNT_NOT_IN_ENTERPRISE`. The user can only proceed with the upgrade after the admin corrects the policy with a valid primary account.