After knowing how to upload alpha/beta/prod versions in the Google Play console, the next question is how to relate the priorities in UEM with the tracks in Play console. Given the scarce documentation, I admit I was very confused on how this should work. If in UEM, device is assigned first to Alpha track and in Play console the track is empty, does the device go see if it's also assigned to Beta? Do the priorities in UEM matter? Does the version code in Play console matter?
Well, here's the breakdown! (Disclaimer: applies to Workspace ONE UEM 1909 and above)
1. In UEM, let's assign the app in this priority: Alpha (0) > Beta (1) > Prod (1)
2. For each of the devices the app is assigned to, UEM gets the FIRST track it is assigned to and passes this info to the Play console. For example:
Device A --> Alpha Track
Device B --> Beta Track
Device C --> Production Track
3. On the Play console side, when a device is assigned to a track (Alpha/Beta), it is also approved for the Production track. Devices assigned to Production just gets approved for Production. The device will then receive the highest version among the tracks it is approved for.
4. Bonus scenarios:
- When a Production track has a higher version than Alpha/ Beta, the lower version/s gets "superseded".
- An alpha/ beta app can be released to Production. This results in the app being "promoted".
- For both scenarios above, rule that the device will receive the highest version among the tracks it is approved for applies.
5. Let's try the scenarios with devices A, B, and C. The items in red for the tracks are the changes in Play console. The items in blue at the bottom of the table means there was a resulting change in version installed on the device.
| Action Done | Released 1.1/1.2 to Alpha/Beta | Released 1.3 to Prod | Released 2.1 to Alpha | Released 2.2 to Beta | Promote 2.2 to Prod | Released 2.3 to Alpha | |
| Track | State 1 | State 2 | State 3 | State 4 | State 5 | State 6 | State 7 |
| Alpha | (empty) | 1.1 | superseded | 2.1 | 2.1 | superseded | 2.3 |
| Beta | (empty) | 1.2 | superseded | superseded | 2.2 | promoted | promoted |
| Prod | 1.0 | 1.0 | 1.3 | 1.3 | 1.3 | 2.2 | 2.2 |
| Device | |||||||
|---|---|---|---|---|---|---|---|
| A | 1.0 | 1.1 | 1.3 | 2.1 | 2.1 | 2.2 | 2.3 |
| B | 1.0 | 1.2 | 1.3 | 1.3 | 2.2 | 2.2 | 2.2 |
| C | 1.0 | 1.0 | 1.3 | 1.3 | 1.3 | 2.2 | 2.2 |
Note:
Pre 1909, whitelisting behavior from UEM to Play console is different such that in item 2, behavior is as follows:
Device A --> Alpha Track --> Alpha, Beta, and Prod tracks approved
Device B --> Beta Track --> Beta and Prod tracks approved
Device C --> Production Track --> ONLY Prod track approved
Same Play console rule applies: The device will receive the highest version among the tracks it is approved for.
Below is the sample behavior pre-1909
| Action Done | Released 1.1/1.2 to Alpha/Beta | Released 1.3 to Prod | Released 2.1 to Alpha | Released 2.2 to Beta | Promote 2.2 to Prod | Released 2.3 to Alpha | |
| Track | State 1 | State 2 | State 3 | State 4 | State 5 | State 6 | State 7 |
| Alpha | (empty) | 1.1 | superseded | 2.1 | 2.1 | superseded | 2.3 |
| Beta | (empty) | 1.2 | superseded | superseded | 2.2 | promoted | promoted |
| Prod | 1.0 | 1.0 | 1.3 | 1.3 | 1.3 | 2.2 | 2.2 |
| Device | |||||||
|---|---|---|---|---|---|---|---|
| A | 1.0 | 1.2 | 1.3 | 2.1 | 2.2 | 2.2 | 2.3 |
| B | 1.0 | 1.2 | 1.3 | 1.3 | 2.2 | 2.2 | 2.2 |
| C | 1.0 | 1.0 | 1.3 | 1.3 | 1.3 | 2.2 | 2.2 |
Special thanks to Jason Huang, Kevin Murray, Glen Friedman, and Michael Gow for helping breaking down the components with me.