List Explorer
Settings, views and versions for a site's lists
Every list and library on one site, with the same settings tabs Tenant Explorer shows for a list: name and description, versioning and approval, validation and item-level security, IRM, audience targeting, forms and indexed columns, and each list's views with their columns and CAML query. Plus bulk show / hide across many lists at once. Built to run on an ordinary user sign-in: unlike Tenant Explorer it makes no Microsoft Graph call, so it needs no app registration and no admin consent - a site owner with a browser sign-in can use it.
What it does
- Every list and library on the site, including the ones already hidden.
- Which are hidden and which appear in Site contents.
- Each one's settings - versioning, approval, validation, IRM, audience, forms, indexed columns.
- Each one's views, and the CAML query and columns behind every view.
- How many items each holds, so you can see what a version limit would apply to.
How it runs
- Sign in. One tenant, asked when you click the tile. Any of the three credentials works here.
- Choose a site. The shared site picker, or paste a URL.
- Click a list. Its settings open on the right, in the same tabs as Tenant Explorer. Expand it for its Views; select a view to edit its columns and CAML.
- Save. Each settings tab has its own Save. For bulk show / hide, tick several lists, stage the change, and use the Save button at the bottom.
How it works
Opening a site reads its lists and libraries, hidden ones included, and nothing more. Version settings are a separate read, made only for the lists you tick and ask for, one list at a time with each named as it goes. A list whose settings could not be read stays marked as not loaded rather than being shown with made-up defaults.
Show and hide are staged on the rows first and sent only when you press Save. All the staged show and hide changes are sent together, and each list's own answer comes back to its row. Version-setting changes are sent one list at a time, because each list's combination is checked (minor versions and check-out need versioning on) and one list can be refused without affecting the others.
A row is marked Saved only when SharePoint answered for that list. A list it gave no answer for, or one the save never reached because you stopped it, is marked as not confirmed or not saved, with Reload as the way to check. If a row changed both its visibility and its version settings and one of them failed, that failure is reported on the row and the other change is not rolled back.
Turning versioning off on a list that has it is asked about once, naming the lists, before anything is sent. There is no history of changes on this screen: a hidden list is shown again the same way it was hidden, and a version setting is changed back by editing it again. Sending a whole list away from the Danger zone puts it in the site recycle bin, where it can be restored.
What you need
- Manage Lists permission on the site - site owner or better. No tenant-level role, and no admin consent: this screen runs entirely on SharePoint's own APIs, so a browser sign-in is a complete credential for it.
What it will not do
- One site at a time. It is a settings editor, not a tenant-wide sweep.
- Turning versioning OFF discards the version history SharePoint holds for that list, and that cannot be undone from here - so it is confirmed separately before it is sent.
- Lowering a version limit does not trim existing history by itself; SharePoint applies the new limit as items are next updated. To reclaim space now, use Version Trim.
- Hidden lists are hidden from people browsing the site. It is not a permission - anyone with the URL or the list id still reaches the content.
- Permissions and the items / files inside a list are not shown here - both are read through Microsoft Graph. Open the list in Tenant Explorer for those.