Targeted release for particular users

[Deleted]

I have a question around how targeted release for specific users works for Office 365 (I am not talking about client applications). I can see for certain features which are user-centric that this makes sense.

For base platform things though I can't see how that would work for everything. If you have a fundamental change to the underlying platform then surely that is an all or nothing change for all users? It could be targeted in that it is applied for all users or if you chose certain users only then that particular change is held back until standard release? Is there any documentation for this anywhere?

[#2]

Hi Mark

Certainly is documentation for Targeted release - right here

https://docs.microsoft.com/en-us/office365/admin/manage/release-options-in-office-365?view=o365-worl...

As stated in the article 'You can choose to have individuals or the entire organization receive updates early'

Hope that helps and answers your question! If so, please like and set as the solution! If not, let me know what more you need. Thanks for raising this to the Tech Community.

Best, Chris

[#3]

Thanks but I should have probably been clearer in my question :) 

I have read that documentation but I wanted to know if there are changes which can occur which do not go through the targeted -> standard cycle for certain users as it doesn't make sense to only have that particular change for a sub-set of users?

[#4]

Sure, I get what you mean.

It always goes through the Targeted > Standard cycle as per that article. There is also the option of having users added to the insider programs

Office: https://insider.office.com/en-us/ 

Microsoft 365: https://insider.windows.com/en-us/signup/microsoft-365-insider-please-sign-in/

The insider programs are to test and feedback on the bleeding edge functionality prior to it entering targeted release. I would advise caution on enrolling users into insider programs because these can have a number of bugs and cause issues on machines. Some applications such as Teams have developer previews which are designed for developers to get early access to builds in order to develop and test applications.

Whether to have a subset of users on Targeted is really a personal choice. Some organisations I work with would say it is essential in order to preview functionality so it helps IT be ahead of the curve when the rest of the organisation is on the standard release. This is more prevalent in larger organisations with dedicated IT Teams Other organisations just have the whole organisation on the standard release once the functionality has been tried and tested. This is more common amongst SMB's or organisations which want a flat standardised release across all users. It is much rarer to have organisations wholly on the targeted release: these tend to be IT/Pro Service organisations.

Hope that helps!

Best, Chris

[#5]

Being on targeted release, you won't get all the changes that say a first release entire tenant would see due to some things requiring like you said entire back end changes. Sometimes from my experience as well you will get a feature but it won't work for those users because it's not all users. It may have changed recently where they do a better job of that, but tenants with select users won't get ALL the exact same features that a tenant set to that will all the time, but most of the time the Select Users will get them first.

[#6]

Thanks - I figured as much and I guess in those cases they just hold it back until ready for everyone.

The reason I am after clarification is in designing a path to live for a large corporate. There was a feeling internally that we could simply assign only some users to be on targeted release and that would give us enough of a heads up to some of the changes coming. I feel that really you need at least a whole environment before prod on Standard release which is where you test and then another one before that on targeted for everyone in order to see upcoming changes across the board. 

[#7]

The biggest issues I have with the Targeted Release process, is the fact that many services/apps don't use this process and many feature updates just show up and the only way to know that you have it is trial and error.

The problem with having a separate tenant, is that there is no way to control which tenant gets an update. It is quite possible for a "Prod" tenant to get an update before a "Test" tenant.

[#8]

That's a good point actually. I wasn't aware that a fair amount of stuff might bypass targeted release...it's all a bit wild west then. If you happen to build processes, both people and code based it can take a long time to get those changed in a large corp environment.

[#9]

It sounds like the solution, from what you are saying Mark is to have all users on the standard release which will avoid the issues of having any users on targeted. I don't think anything from our personal experiences point towards targeted for either a subset of users or the whole organisation.

Best, Chris

[#10]

I have never been able to find a listing of which services/apps actually use the Targeted Release process. I know for sure that Teams, Yammer, PowerApps, Flow, and PowerBI do NOT.

Changes to the Security and Compliance Center services do not seem to use it.

Changes to the O365 and other Admin Centers do not use it, i.e, you have have some admins test some new admin features before other admins. However, each global admin can decide to use the new Preview version of the Admin center if they want to.

Some stuff from SPO does go through it but a lot does not.