New list experience breaking existing views

[shaipetel]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

not applicable

Developer environment

None

What browser(s) / client(s) have you tested

• [ ] 💥 Internet Explorer
• [X] 💥 Microsoft Edge
• [X] 💥 Google Chrome
• [ ] 💥 FireFox
• [ ] 💥 Safari
• [ ] mobile (iOS/iPadOS)
• [ ] mobile (Android)
• [ ] not applicable
• [ ] other (enter in the "Additional environment details" area below)

Additional environment details

Not relevant

Describe the bug / error

@reedpamsft - you've asked to be tagged on those issues with new modern experience tagging @natalieethell as well for transparancy

A new list experience was released last Friday October 4, 2024 and it is breaking existing list views. We've had a list we used for years, classic UI and modern UI worked fine until this new version rolled out, now it shows this error message:

Steps to reproduce

I'm not sure how to reproduce, as I mentioned above - we have not made any changes to this list. I would try to create a list with many lookup columns and put them in the list view.

Expected behavior

Pre-existing views should still work.

[shaipetel]

Is MSFT not following the targeted release anymore? is there another way for us to be able to taste/test the drops before they hit production?

This issue and the forms opening in a dialog instead of a side panel did not happen on our targeted release test tenant, and appeared on our production environment for the first time.

We have a dedicated QA tenant that is on targeted release, but seems like it is not getting the updates before they hit production as it was in the past.

This is very concerning, as it happened several times already that updates appear on production either before or at the same time they appear on targeted release.

[reedpamsft]

@shaipetel does this happen when you go to the view, or when you try to save a value?

[reedpamsft]

@shaipetel anyway, you can hide columns by going into the list settings, then going to any views with the issue, and unchecking lookup columns so they don't show up. The handling of lookup columns hasn't changed between the new and old UI; is it possible that someone added another lookup column and you weren't aware of it?

[chr-sad]

@shaipetel we don't have the same problem with the broken views, but we have also noticed several times in our setup or with customer tenants that changes & thus problems occur on production systems before they appear on our targeted release tenant - which is, as you mentioned, very concerning!

[shaipetel]

@shaipetel does this happen when you go to the view, or when you try to save a value?

Just by visiting the list view.

[shaipetel]

@shaipetel anyway, you can hide columns by going into the list settings, then going to any views with the issue, and unchecking lookup columns so they don't show up. The handling of lookup columns hasn't changed between the new and old UI; is it possible that someone added another lookup column and you weren't aware of it?

No the view hasn’t changed in a long while. It broke exactly when the list UI changed to the new one so doesn’t sound like a coincidence

[shaipetel]

@shaipetel we don't have the same problem with the broken views, but we have also noticed several times in our setup or with customer tenants that changes & thus problems occur on production systems before they appear on our targeted release tenant - which is, as you mentioned, very concerning!

Indeed and I’d love to hear MSFT comments on this practice. Certainly hasn’t been the case in the past.

@VesaJuvonen or @reedpamsft perhaps you can clarify?

[reedpamsft]

Thanks @shaipetel . I'll look into the back-end details for your list and see what might be causing this.

Regarding release timelines, we have two procedures by which we release features. One is as a 50/50 Control / Treatment set of users, and the other is just releasing to all users. In both cases, rollout starts with First Release users and then proceeds through Standard users after, so in both cases a release can't reach standard users until it has been rolled out for First Release users.

However, you'll notice in the 50/50 case that only half of First Release users will see something before it goes out to Standard users (eg: a First Release user who is in the Control, and a Standard User who is in the Treatment). As mentioned, we use that method as a way to flush out issues that may affect only certain environments by comparing reliability, performance, and other metrics for control and treatment users. We have received a few complaints now about the fact that this results in Standard users seeing a feature that a First Release user might not, and we're evaluating that feedback as it relates to the way in which we conduct those types of rollouts in the future.

What you are likely seeing is that the new UI is being rolled out for Web Parts as a 50/50 release.

[shaipetel]

@reedpamsft so, does that mean there are chances that some updates will show up on a production tenant before they show up on my first release tenant?

But that was the whole point of the first release, for me to have nightly testing done on that and know before something breaks in production.

Is there a way to ensure my test first release tenant gets those updates early?

[andrewconnell]

@reedpamsft I'll echo what @shaipetel said...

But that was the whole point of the first release, for me to have nightly testing done on that and know before something breaks in production.

Your response is the first I'm seeing that there's a chance first release won't see changes first. That's a deviation from the original messaging I've always heard from Microsoft about first release. I understood occasional high-priority hotfixes sometimes were pushed all the way out, taking time to propagate to all tenants & regions, but I've never heard of normal rollouts sometimes not getting this.

I just reread the docs Set up the Standard or Targeted release options... with all due respect, what you outline does not mesh with this page. Specifically:

Targeted release for entire organization If you Set up the release option in the admin center for this option, all your users will get the Targeted release experience. For organizations with more than 300 users, we recommend using a test subscription for this option.

[Tanddant]

If I'm understanding this thread correctly, not only is there a 50% chance one of my end users will see a change before my targeted release users.

I also have absolutely no way to actually guarantee that my "power users" are seeing the newest updates? - meaning there's no way for IT or the power users to replicate issues that end users are reporting.

While this in no way matches my expectation for how this should work, it 100% matches my experience these past few months.

We ideally need a way to force an update to a user, and or allow us to roll back the update from a user.

I had clients where 5 folks were unable to work properly for 2 weeks earlier this year - no help from support cause "SPFx is custom code, that's your problem", and no way to replicate/debug the issue on my end cause my targeted release user wasn't getting the updates.

[reedpamsft]

As mentioned, I'm pushing for a reevaluation of the process I mentioned. I also don't and can't speak for Support and what they may have said on past cases.

[reedpamsft]

@shaipetel just as a note, your default view (allitems.aspx) does indeed contain 13 lookup columns in it, which is why you're getting the error. Most of the time when a column is added, it gets added to the view you're currently on, so it's quite possible that exceeding the lookup threshold happened by accident. As mentioned, you'll need to remove lookup columns to get back under the threshold, which is something that's the same in both the old and new UI's. Note that User fields are implemented as lookup fields (and have been since the origin of SharePoint), so you might not realize quite how many lookup fields you're using.

[sympmarc]

I'll agree that the description of the rollout process above is inconsistent with what is documented, and we've been told for years. First release (or targeted release) for either specific users or the tenant is supposed to be how people can see functionality before it rolls out to any larger subset of users/tenants. If this has changed, you need to be documenting it an explaining it very clearly and publicly. But understand that this is not how it's worked for many years - or at least what the SLA has been.

As several people above have mentioned, many orgs have separate tenants they use as First Release just so they can see changes before they roll out more broadly.

BTW, this isn't a "Support" thing - it's a Product Group thing: this was the commitment from the Product Teams.

[shaipetel]

@shaipetel just as a note, your default view (allitems.aspx) does indeed contain 13 lookup columns in it, which is why you're getting the error. Most of the time when a column is added, it gets added to the view you're currently on, so it's quite possible that exceeding the lookup threshold happened by accident. As mentioned, you'll need to remove lookup columns to get back under the threshold, which is something that's the same in both the old and new UI's. Note that User fields are implemented as lookup fields (and have been since the origin of SharePoint), so you might not realize quite how many lookup fields you're using.

thanks, the view or list haven't changed and works on the modern UI, not on the new modern lists (can we give this a better name?).

[shaipetel]

@reedpamsft I'll echo what @shaipetel said...

But that was the whole point of the first release, for me to have nightly testing done on that and know before something breaks in production.

Your response is the first I'm seeing that there's a chance first release won't see changes first. That's a deviation from the original messaging I've always heard from Microsoft about first release. I understood occasional high-priority hotfixes sometimes were pushed all the way out, taking time to propagate to all tenants & regions, but I've never heard of normal rollouts sometimes not getting this.

I just reread the docs Set up the Standard or Targeted release options... with all due respect, what you outline does not mesh with this page. Specifically:

Targeted release for entire organization If you Set up the release option in the admin center for this option, all your users will get the Targeted release experience. For organizations with more than 300 users, we recommend using a test subscription for this option.

Definitely @andrewconnell - I was blindsided on production by customers / users seeing things lately that were never discovered in our nightly tests. What makes it worst is that it seems totally random, like 2-3 random users will get an update for a day or two sometimes, then it will either roll back or roll out to everyone.

It may affect just a few users, just a few sites, or sometimes just a few lists.

I would be fine with all of that @reedpamsft if I had a way to guarantee a specific user(s) will get the updates first - we run tests nightly on a first release environment, I just need that to get the updates first so I have a heads up before production.

[aaclage]

What makes it worst is that it seems totally random, like 2-3 random users will get an update for a day or two sometimes, then it will either roll back or roll out to everyone.

Had similar situation where some users had new update other users didn't in Prod. https://github.com/SharePoint/sp-dev-docs/issues/9965

[rmillener]

This is an absolute disaster for us. Can we get a timeline on when this change to targeted release was implemented?