Microsoft Lists: SharePoint Lists, hide from users?

[digiservice]

I appreciate this question spans across multiple Microsoft products but I am hoping someone can help me.

Our tenant now has Microsoft Lists.

We are little concerned as we have a number of PowerApps that use SharePoint Lists as their main data source and now these a entirely visible to the users.

Previously it was fairly easy to hide the lists from users so they could not easily interact with the data outside of the PowerApp.

Now with Microsoft Lists the users can see all Lists they have access to, and much more easily circumvent using the PowerApp to edit the data directly. 

If you were to use SQL or CDS, you would give read/write permissions to the relevant data but most likely never grant the user direct access to the server or datastore.

Is there then a similar permissions structure to achieve access to the data but not access directly to the SharePoint List itself?

Is there a means we can at least hide the SharePoint Lists from the Microsoft Lists dashboard/home page?

Any help or advice appreciated!

[jlalonde]

We have the same need.

[v-jefferni]

Hi @digiservice ,

Thank you for your reply.

Please check below official doc to see the limits of Lists right now:

https://docs.microsoft.com/en-us/microsoftteams/manage-lists-app#what-you-need-to-know-about-lists

Note:

At this point, owner and member permissions in a team aren't linked in any way to permissions in the team site that govern the behavior of lists or the Lists App. However, based on customer feedback and usage, this will be considered for a future iteration of the product.

Hope this helps.

Best regards,

Community Support Team _ Jeffer Ni
If this post helps, then please consider Accept it as the solution to help the other members find it.

[JosephCrockett]

This is unconfirmed by anyone, but if you "hide" the list, it does appear to hide it from MS Lists. This does require knowledge of PowerShell and PnP PowerShell. It also will hide the list from the Site Contents screen.

I say it's unconfirmed, because I didn't find this documented anywhere -- so it may change (without warning) and also may not work like I think it does. Aside from those warnings, it did work for me.

[HEATFreight]

@JosephCrockett but what if we want the underlying SharePoint lists to remain "visible" to users?

We've taken great pains to remove every bit of user interface "fluff" from our SharePoint site so that users can't easily interact with the SharePoint lists that make up the backend of our app. Users must have edit/view permissions enabled on these lists, or they'd not be able to use the app. Some lists have specific permissions to enable the functionality we need.

What we don't need is Microsoft Lists (as differentiated from SharePoint lists). We went to all this trouble to lock down the SharePoint site to avoid users getting into the backend and accidentally breaking things by editing their records. Although they would only be able to edit their own records, this would still cause all kinds of trouble. The app itself enforces certain rules that the SharePoint lists do not (because we haven't attempted to figure out input validation directly within SharePoint columns yet). Thus if the users mess with the backend data contained in these SharePoint lists, they will wreak havoc. But this is substantially less likely because, even if they somehow do figure out how to navigate to the SharePoint site, they would then have to figure out the list names. There is no way to just click into those lists... EXCEPT FOR FRICKIN' MICROSOFT LISTS! What a flippin' piece of garbage.

We just want to make Microsoft Lists go away. We don't need it or want it. If we had known building a robust backend in SharePoint would be so involved, we would have just taught ourselves SQL instead. Total garbage. Fix this Microsoft!

You create products no one asked for that duplicate functionality unnecessarily. It's maddening. Somebody just please make it all go away!

[HEATFreight]

@v-jefferni Is this advice specific to Teams?

We've disabled Microsoft Lists in Teams. We've disabled all apps and all 3rd-party apps at Org level. We've disabled the lists "feature" in the site settings. Yadda, yadda, yadda... we don't see anything left to do.

Why is it still possible to navigate to Microsoft Lists from within our SharePoint site? Only our admin users should be able to navigate using navigation links with audience targeting, but there seems to be no audience targeting for the Microsoft Lists button in the navigation pane. Do we have to disable the navigation pane for everyone just to make frickin' Microsoft Lists go away?!?!?!

What a nightmare. How can anyone use SharePoint for any robust sort of application if it's nearly impossible to block users from easily clicking into the backend and breaking stuff??? Seems as if we need to apply extensive input validation to all SP list fields such that no invalid inputs can be created even when editing directly in SharePoint.

There should be an easier way to make Microsoft Lists just not be a thing. We want to kill Microsoft Lists. We want to crush it beneath the vice-like grip of our fists, hardened and tightened with the perpetual rage induced by the mere existence various Microsoft products and services and the documentation thereof. We will vanquish Microsoft Lists and banish it to The Upside Down. One way or another, victory will be ours.

[maria3]

Has anyone found a good solution for this? Like others have mentioned above, I would like to start using SharePoint lists as the data source for PowerApps, but I do not want end users to be able to access the data source outside of the PowerApp via the app bar.

[lowcodemyass]

Come on, sort it out Microsoft!

[maria3]

I found a way to hide specific lists. In Power Automate, you can use the "Send an HTTP request to SharePoint" to adjust the list settings and set Hidden to true, IsPrivate to true, and No Crawl to true. You would then need to run this flow once for each list you want to hide. I just figured this out yesterday and so far this seems to have done what I was expecting.