Tag: SharePoint

How SharePoint environments can be improved for Copilot results

image

The short answer is this:

Copilot results are only as good as the SharePoint environment underneath them. If your SharePoint is messy, overshared, full of duplicate files, stale content, and inconsistent naming, Copilot will surface messy, duplicate, stale content. If SharePoint is well-structured, governed, and maintained, Copilot becomes dramatically more useful.

From everything I’ve seen in SMB environments, improving SharePoint for Copilot usually delivers a bigger productivity gain than buying additional AI licences.

1. Fix permissions and oversharing first

This is the most important step.

Copilot doesn’t magically know what information is important. It relies on Microsoft Graph and existing permissions. If users can access content they shouldn’t, Copilot can discover and surface that content.

Common problems

  • Everyone has access to everything

  • Legacy project sites never cleaned up

  • Anonymous sharing links still active

  • “Everyone except external users” permissions

  • Former employees still own sites

What to do

  • Review site permissions

  • Remove unnecessary access

  • Review sharing links

  • Remove broad access groups

  • Identify inactive sites

  • Implement site lifecycle management

SharePoint Advanced Management and Data Access Governance reports were specifically highlighted as ways to identify oversharing risks before Copilot rollout.

2. Create a proper information architecture

Many organisations have:

Documents
├── New Folder
├── Old Stuff
├── Final
├── Final V2
├── Copy of Final
└── Misc

Copilot struggles because the business itself has no structure.

Instead build:

Finance Hub
├── Budget Planning
├── Forecasting
├── Reporting
└── Policies

Sales Hub
├── Proposals
├── Customers
├── Pricing
└── Marketing

The clearer the structure, the easier it is for:

  • SharePoint Search

  • Microsoft Search

  • Copilot Chat

  • SharePoint Agents

  • Copilot Agents

to locate relevant content.

3. Improve file naming standards

Copilot does read document content, but filenames still matter.

Bad:

Proposal.docx
Proposal New.docx
Proposal Final.docx
Proposal Final Final.docx

Good:

CustomerName-Proposal-2026-07.docx
CustomerName-SOW-v1.docx
CustomerName-SOW-Approved.docx

In one of your SharePoint discussions, naming conventions were specifically called out as something that should be standardised across the site.

4. Use metadata instead of folders where possible

Metadata is one of the biggest Copilot improvements available.

Rather than:

Projects
 ├── Sydney
 ├── Melbourne
 ├── Brisbane

Use columns such as:

Column
Value

Client
ABC

Region
Sydney

Project Type
Migration

Status
Active

This gives Copilot richer context when searching and grounding answers.

Instead of finding a file based only on its location, Copilot can reason over:

  • client

  • project type

  • status

  • department

  • business owner

5. Remove stale content

One major challenge is outdated content appearing in search results.

Microsoft now provides features that recommend:

  • demoting inactive pages

  • identifying content gaps

  • fixing broken links

to improve discoverability and Copilot relevance.

Ask yourself:

  • Is this document still current?

  • Is there a newer version?

  • Does anyone own it?

  • Should it be archived?

A common issue is Copilot finding a policy from 2019 while a better one exists from 2026.

6. Identify authoritative sources

One of the newest improvements is the ability to mark SharePoint sites as authoritative.

Examples:

  • HR

  • Finance

  • Legal

  • Corporate Communications

Content from these sites can be prioritised in Copilot Search and Copilot Chat results.

For example:

Site
Why make it authoritative?

HR
Official policies

Finance
Budgets and governance

Legal
Contracts

Company Communications
Executive announcements

This helps reduce contradictory responses.

7. Apply sensitivity labels

Copilot respects sensitivity labels and information protection controls.

Typical labels:

  • Public

  • Internal

  • Confidential

  • Highly Confidential

Benefits include:

  • Better governance

  • Controlled sharing

  • AI visibility controls

  • Better compliance outcomes

8. Improve search quality

Copilot depends heavily on Microsoft Search.

Poor search equals poor Copilot.

Things that help:

Create quality pages

Instead of storing everything in Word documents:

  • Create SharePoint pages

  • Add summaries

  • Add FAQs

  • Add ownership information
Add page owners

Every key page should have:

  • business owner

  • review date

  • contact person
Use meaningful titles

Bad:

Welcome
General Information
Policies

Good:

Employee Leave Policy
Expense Claim Procedure
Remote Work Guidelines

9. Build hub sites

Hub sites create logical business groupings.

Example:

Corporate Hub
 ├── HR
 ├── Finance
 ├── Operations
 └── IT

Customer Hub
 ├── Sales
 ├── Marketing
 └── Service

Hub sites improve navigation, search context and content relevance for Copilot.

10. Create SharePoint agents for specialised knowledge

Where a user only needs answers from a particular area, create a SharePoint Agent.

Examples:

  • HR Agent

  • Policy Agent

  • Finance Agent

  • Project Agent

These agents ground themselves on specific SharePoint locations and often produce more accurate answers than tenant-wide searches.

11. Add more organisational context

Copilot works best when content explains:

  • who owns it

  • what it is for

  • where it applies

  • when it was reviewed

Bad document:

Procedure.docx

Good document:

Financial Approval Process
Owner: Finance
Review Date: July 2026
Applies To: Australia Operations

The extra context significantly improves grounding quality.

12. Measure and improve continuously

The best Copilot environments are not set-and-forget.

Establish a quarterly process:

Review
  • Oversharing

  • Inactive sites

  • Broken links

  • Orphaned content
Clean up
  • Duplicate files

  • Old projects

  • Stale policies
Improve
  • Metadata

  • Authority sites

  • Labels

  • Search experience

Data Access Governance reports and Content Management assessments are specifically designed for this ongoing process.

My practical SMB recommendation

If I were preparing a tenant for Copilot today, I’d prioritise:

  1. Permission cleanup

  2. Oversharing remediation

  3. Sensitivity labels

  4. Review inactive sites

  5. Standard naming conventions

  6. Create hub sites

  7. Add metadata

  8. Designate authoritative sites

  9. Build targeted SharePoint agents

  10. Quarterly governance review

In most SMB tenants, doing just those ten things improves Copilot results more than any prompt engineering or user training because you’re improving the quality of the information Copilot can see and trust.

The Business Doubled When I Started Cutting, Not Adding

MAI_04847cec600d83e4

For years I ran my business trying to make it look impressive. Impressive to peers, to prospects, to whoever happened to be watching at a networking event. Every new tool, every new process, every clever workaround was another thing I could point to and say, look how sophisticated this is. The problem is that nobody scales a business off how it looks from the outside. They scale it off how it actually runs on a Tuesday afternoon when three clients call at once.

Somewhere along the way I stopped building for the audience and started building for me. For how the work felt to do. That single shift is the closest thing I have to a real explanation for how we went from eight million a year to twenty.

The mess was self-inflicted

Here’s the uncomfortable part. The complexity that was strangling the business wasn’t forced on me by clients or by Microsoft or by the market. I built it. Every duct-taped process was a decision I made at some point to patch a problem rather than fix it. A spreadsheet here to track what a proper system should have tracked. A manual checklist there because nobody trusted the automation. A Teams channel for this, a separate one for that, a third one nobody remembered the purpose of.

None of it was wrong on the day I added it. It was all reasonable in isolation. But reasonable decisions stacked on top of each other for five years become a structure that no one person can hold in their head. And when no one can hold it in their head, everything slows down. People stop deciding and start asking. The business gets heavier with every fix.

Why adding more is the instinct, and the trap

When things feel chaotic, the instinct is to reach for another tool. New ticketing platform. New project board. Another layer of approval to stop the mistakes. It feels like progress because you’re doing something. But you’re usually just adding another joint to a structure that already has too many.

I had to break that habit in myself first. The question I started asking wasn’t “what can I add to fix this” but “what can I remove so this stops happening at all.” Removal is harder. It means admitting that something you built no longer earns its keep. It means killing the spreadsheet you were quietly proud of.

This is where I leaned on the Microsoft 365 stack properly rather than around it. We were running four overlapping trackers, so I had Copilot in Excel pull them apart and show me where the same data lived in three places. Then we cut it to one source of truth in SharePoint and let Copilot answer the questions people used to dig through the others to find. The chat channels got the same treatment. Half of them went. The ones that stayed got a clear job, and when someone asked “where does this go,” the answer was finally obvious.

Simplicity is a discipline, not a milestone

The thing nobody warns you about is that simplicity doesn’t stay. It’s not a state you reach and then relax. Complexity creeps back the moment you stop watching, because every small patch feels harmless in the moment. So now I run a regular review where the only acceptable change is a subtraction. What process can we retire. What approval step is just fear wearing a hat. What report does nobody actually read. I use Copilot to summarise where time is going across the team’s Outlook and Teams activity, and more often than not it points straight at something we could stop doing entirely.

That review is the most valuable hour in my month. Not because it adds capability, but because it protects the lightness that let us grow in the first place.

The takeaway

If your business feels stuck and heavy, resist the urge to bolt on one more thing. You almost certainly don’t have a tooling gap. You have an accumulation problem, and you built the accumulation yourself, one sensible patch at a time. Growth didn’t come to me from being more elaborate. It came from being willing to cut, to trust the simpler version, and to stop caring whether it looked clever to anyone else.

The hard part isn’t knowing what to remove. It’s having the nerve to actually pick up the scissors.

Certificate-Based Authentication for SharePoint Online: The Bit Everyone Avoids

image

There’s a point every SharePoint admin eventually hits.

The script works.
The logic is solid.
But it still needs a username.

And that’s where it falls apart.

Because anything that relies on a human login isn’t automation. It’s just a task waiting to break the moment MFA tightens, conditional access changes, or the account gets locked.

Certificate-based authentication fixes that. It has for years.

The problem hasn’t been what to do.
It’s been how much effort it takes to do it properly.

The Problem Isn’t Authentication. It’s Assembly.

If you’ve ever set this up manually, you’ll know the sequence:

  • Create or import a certificate

  • Register an app in Entra ID

  • Assign API permissions like Sites.FullControl.All
  • Upload the certificate

  • Grant admin consent

  • Capture the thumbprint

  • Wire it all into your PowerShell scripts

None of it is particularly hard.

But it’s fragmented, fiddly, and very easy to get wrong.

Which is why most environments quietly fall back to interactive sign-ins… right up until they stop working.

What This Approach Actually Does

I’ve been written a new script —

https://github.com/directorcia/Office365/blob/master/o365-connect-spo-cert.ps1

with full documentation here – https://github.com/directorcia/Office365/wiki/Certificate-based-authentication-for-SharePoint-Online

The script behind this approach is designed to remove that friction.

Instead of documenting the steps, it executes them.

At a high level, it runs in one of two modes:

1. Generate Everything Locally

-GenerateLocalCertificate

This builds the foundation:

  • Creates a local certificate (optionally exports a PFX)

  • Can provision an Entra app automatically

  • Assigns required permissions (including SharePoint and Graph)

  • Prepares everything needed for ongoing use

It effectively handles the “setup once” phase.

2. Use Certificate Authentication

-UseCertificateAuth

This is the day-to-day mode:

  • Connects to SharePoint Online using the app and certificate

  • No username

  • No password

  • No MFA prompt

  • No interaction required

Just a clean, repeatable connection into the SharePoint admin endpoint. [github.com]

Why This Matters More Than It Looks

At face value, this is just authentication.

In reality, it’s capability.

Once your connection is non-interactive, a whole class of work becomes possible:

  • Scheduled SharePoint reporting

  • Overnight clean-up jobs

  • Site lifecycle management

  • External sharing audits

  • Compliance checks

All the tasks that were “nice ideas” suddenly become operational.

Because they no longer depend on someone being present.

That’s the real shift.

The Security Side (That People Miss)

There’s also a security upside that often gets overlooked.

Certificate-based authentication:

  • Removes passwords from scripts entirely

  • Reduces exposure to phishing and credential theft

  • Uses a service principal instead of a human identity

  • Allows tighter, scoped permissions (like Sites.Selected)

In short, it’s both more secure and more predictable than traditional login methods.

The Gotcha Everyone Hits Once

If you build this from scratch, you’ll probably hit the same issue most people do:

It doesn’t work immediately.

Not because it’s broken — but because permissions need time to propagate across Entra ID and SharePoint.

That delay is normal.

It’s also the main reason people abandon setups halfway through and revert to “just use an account”.

Where This Fits for MSPs

If you’re managing multiple tenants, this becomes even more valuable.

The pattern is simple:

  • One script

  • One certificate per tenant

  • One app registration per workload (or per tenant, depending on your model)

  • Store the mapping once

  • Reuse it everywhere

From there, your tooling becomes predictable.

No credential prompts.
No dependence on admin accounts.
No surprises when security policies tighten.

The Bottom Line

Certificate-based authentication isn’t new.

It’s just been inconvenient.

What this approach does is remove the inconvenience.

And once you do that, you start using it everywhere.

Because the real benefit isn’t the connection.

It’s everything that becomes possible after it.

Source material

Where Do Your Uploaded Documents Actually Go in Copilot Notebooks?

image

One of the questions I get asked most often about Microsoft 365 Copilot Notebooks is deceptively simple: when I upload a document into a notebook, where does it actually live? It’s a fair question. If you’re an MSP, an administrator, or anyone responsible for governance, “it’s in the cloud somewhere” isn’t a good enough answer. You need to know exactly where that data sits, who can reach it, and what compliance controls apply. The answer turns out to be more interesting than most people expect, and it hinges on a relatively new piece of the Microsoft 365 storage platform called SharePoint Embedded.

The short answer: SharePoint Embedded

When you upload a document into a Copilot Notebook, it does not land in your OneDrive, and it doesn’t go into a regular SharePoint site or document library that you can browse to. Instead, it’s stored in SharePoint Embedded — specifically inside a user-owned container.

Here’s the part that surprises people. Copilot Notebooks, Copilot Pages, and Loop’s “My workspace” all share the same single user-owned container per user. You don’t get a separate container for each. The first time you need any one of those experiences, Microsoft provisions one container and reuses it for all three. Even the container’s name depends on which app you opened first: it’s called “Pages” if you visited the Microsoft 365 Copilot app first, or “My workspace” (localised to your Loop language) if you opened Loop first.

There’s a governance wrinkle worth committing to memory: in the SharePoint admin center, in PowerShell, and in Purview audit data, this container’s application name always shows as “Loop” — even when it only holds Copilot Notebooks. There is no separate “Copilot Notebooks” application filter. So if you go hunting for Copilot content in your audit logs and only search for “Copilot”, you’ll come up empty. Look for Loop.

So what is SharePoint Embedded?

SharePoint Embedded is an API-only file and document management system built on the same proven Microsoft 365 storage platform that powers SharePoint and OneDrive. The key word is API-only. Unlike a normal SharePoint site, there’s no friendly web UI you can navigate to. When an application uses SharePoint Embedded, it creates a separate storage partition inside your Microsoft 365 tenant, and the documents in that partition are only accessible through Microsoft Graph APIs — and only to the owning application.

Within that partition, the application stores content in entities called File Storage Containers. Think of a container as an API-only document library: it can hold any file type, supports folders, versioning, search, and co-authoring, but it’s dedicated to and reachable by just the one app that owns it. That isolation is the whole point. The files your Copilot Notebook depends on are walled off from other applications, yet they still benefit from the full richness of the Office stack — you can open an uploaded Word or Excel file in Office for the web straight from the experience.

This is the same architecture Microsoft uses under the hood for Loop and Designer. Copilot Notebooks is simply another first-party consumer of the platform.

The detail that matters most: your data stays in your tenant

This is the line I always emphasise with clients. The storage partition that SharePoint Embedded creates lives inside your own Microsoft 365 tenant. Your uploaded documents do not leave your tenant boundary. That means everything your existing Microsoft Purview controls already do, they continue to do here:

  • eDiscovery — content is discoverable

  • Auditing — actions are logged (remember: under the “Loop” application name)

  • Data Loss Prevention (DLP)
  • Retention policies and sensitivity labels
  • Conditional access

So while the storage mechanism is new, the compliance posture is reassuringly familiar. The data is yours, it’s in your tenant, and your governance tooling applies.

Quotas, limits, and a billing nuance

Here’s a distinction that trips people up. The general, developer-facing SharePoint Embedded model bills storage separately through an Azure pay-as-you-go subscription, and that storage does not count against your SharePoint quota. But Microsoft’s first-party use of it for Copilot Pages and Copilot Notebooks works differently. Copilot Pages and Copilot Notebooks content counts against your organisation’s existing SharePoint storage quota — there’s no separate Azure bill for it. The user-owned container has a hard ceiling of 25 TB, which can’t be raised or lowered.

Lifecycle: tied to the user, with sharp edges

The container’s lifecycle is bound to its owner. Content is private by default, much like OneDrive — there’s no forced sharing. When the owning user’s account is deleted, the container is scheduled for deletion and follows the same lifecycle as OneDrive, including a manual handoff step at departure and the option to permanently reassign the container to a new owner.

One critical warning for anyone planning their data protection strategy: there is no end-user recycle bin for Copilot Notebooks. If a notebook is deleted, neither the user nor an administrator can recover it. That’s a meaningful gap compared to the recycle-bin safety net we take for granted in SharePoint and OneDrive, and it’s worth flagging to end users before they start relying on Notebooks for anything important.

Why this matters

Copilot Notebooks feel lightweight and personal, but underneath sits real enterprise-grade storage that you already know how to govern — just wearing a new name. Knowing it’s SharePoint Embedded, that it surfaces as “Loop” in your admin tools, that it counts against SharePoint quota, and that it has no recycle bin turns “somewhere in the cloud” into something you can actually manage.

Copilot Notebooks storage & governance

SharePoint Embedded platform

CIAOPS Need to Know Microsoft 365 Webinar – June

laptop-eyes-technology-computer_thumb

Now in our tenth year!

Join me for the free monthly CIAOPS Need to Know webinar. Along with all the Microsoft Cloud news we’ll be taking a look at SharePoint Skills.

Shortly after registering you should receive an automated email from Microsoft Teams confirming your registration, including all the event details as well as a calendar invite.

You can register for the regular monthly webinar here:

June Registrations

(If you are having issues with the above link copy and paste – https://bit.ly/n2k2606 )

The details are:

CIAOPS Need to Know Webinar – June 2026
Friday 26th of June 2026
11.00am – 12.00am Sydney Time

All sessions are recorded and posted to the CIAOPS Youtube channel.

Also feel free at any stage to email me directly via director@ciaops.com with your webinar topic suggestions.

I’d also appreciate you sharing information about this webinar with anyone you feel may benefit from the session and I look forward to seeing you there.

Restricted SharePoint Search Is Not the Fix You Think It Is

image

Most people’s first reaction to Copilot and SharePoint goes something like this: “Wait — Copilot can see all of that?”

Then they panic. Then they Google. Then they find Restricted SharePoint Search and flip it on like it’s a fire extinguisher.

I get it. The instinct is right — you should care about what Copilot can reach. But RSS isn’t a security control. It’s a stalling tactic. And if you leave it on too long, it’ll cause more problems than the one you were trying to solve.

What is Restricted SharePoint Search, really?

RSS lets a SharePoint admin maintain an allowed list of up to 100 SharePoint sites. Only those sites show up in organisation-wide search results and Copilot chat responses.

That’s it. It doesn’t change a single permission on a single site. It doesn’t block anyone from accessing anything. It just hides sites from search and Copilot — unless the user has recently visited the site, or it was shared with them in Teams or Outlook. In which case, it shows up anyway.

That’s not a security boundary. That’s a curtain.

Microsoft’s own documentation on RSS says it plainly: this is designed as a short-term solution while you audit permissions and apply proper governance. It’s not meant to stay on.

Step-by-step: Setting up RSS the right way

If you’re going to use RSS — and there are situations where it makes sense — do it in this order.

Audit your active sites first

Open the SharePoint admin centre > Active sites. Filter by activity in the last 30 days. Customise columns to show page views, file counts, and last activity. Export the list to CSV. This is your starting inventory — the sites people actually use.

Review permissions on each candidate site

For every site you’re considering for the allowed list, open its details and check the Permissions tab. Look for “Everyone except external users” or company-wide groups. Those are the oversharing patterns you’re really worried about.

Enable RSS and build the allowed list

RSS is managed through PowerShell — there’s no toggle in the admin centre GUI for this one.

Set-SPOTenantRestrictedSearchMode -Mode Enabled
Add-SPOTenantRestrictedSearchAllowedList -SitesList @("https://contoso.sharepoint.com/sites/intranet","https://contoso.sharepoint.com/sites/hr")

Notice what’s missing? A portal button. That’s deliberate. Microsoft wants friction here because they don’t want you to leave this on.

Plan your exit from day one

Before you enable RSS, set a calendar reminder for 30 days out. That’s your deadline to fix the permissions that made you turn it on in the first place — and then turn it off.

When RSS backfires

Here’s where most people get into trouble. They enable RSS, breathe a sigh of relief, and forget about it. Months later, three things have gone wrong:

Search breaks for everyone. RSS doesn’t just limit Copilot — it limits all organisation-wide search. Your finance team can’t find the policy site. Your HR team can’t find the onboarding hub. Nobody told them you turned this on, so they log a ticket blaming SharePoint.

Copilot gets dumber. With only 100 sites to draw from, Copilot has less information to reference. Answers get vague. Users lose trust. You’ve just paid for Copilot licences and then blindfolded the thing.

False confidence sets in. The admin thinks the problem is solved. It isn’t. RSS doesn’t stop Copilot from surfacing content a user has already accessed. If someone opened that sensitive spreadsheet last week, Copilot can still reference it — allowed list or not.

The actual fix: permissions, not curtains

RSS buys you time. Use it. But spend that time on the thing that actually matters: fixing your SharePoint permissions.

Start with Data Access Governance reports in SharePoint Advanced Management. These reports show you exactly which sites have broad sharing, “Everyone” links, or sensitivity labels missing. That’s your real oversharing map.

Then work through it site by site. Remove company-wide sharing links. Tighten group memberships. Apply sensitivity labels where they belong. This is the work that actually makes Copilot safe — not hiding sites from search and hoping for the best.

Once permissions are clean, disable RSS. Let Copilot use the full breadth of your tenant. That’s how you get value from it.

“We turned on RSS six months ago and Copilot still isn’t helpful.”

That’s not a Copilot problem. That’s an RSS problem.

My recommendation?

Use RSS if you’re deploying Copilot to a tenant you haven’t audited yet and you need breathing room. Thirty days. Not six months. Not “until we get to it.”

Set the allowed list. Fix the permissions behind the scenes. Then take the training wheels off.

If you’re an MSP and you’re not walking clients through this sequence — temporary RSS, permission remediation, RSS removal — you’re either leaving them exposed or leaving them hobbled. Neither looks good at renewal time.

RSS isn’t there to protect your tenant. It’s there to give you a window to actually protect your tenant. Don’t confuse the window with the wall.

Maybe Lists is a better tool?

image

Most SMBs I walk into are tracking something important in the worst possible place.

An Excel file pinned to a Teams channel. A shared OneNote page. A SaaS tracker they pay for monthly because no one told them there was already one in the tenant.

Then they wonder why nothing gets logged, why two people overwrote each other’s edits, and why the boss can’t see what’s going on.

That’s not a process problem. That’s a tooling problem.

There’s a free, already-licensed, surprisingly capable tracker sitting in every Microsoft 365 plan you sell. Most of your clients have never opened it.

What is Microsoft Lists, really?

It’s a structured tracker. Rows and columns, like a spreadsheet — but every column has a type (date, person, choice, number, attachment), so nobody fat-fingers a status into the wrong column.

It lives in SharePoint underneath, surfaces in Teams as a channel tab, and has its own icon on the Microsoft 365 app launcher. Same list, three doors in.

And it brings two things Excel will never give you: a built-in form for people who shouldn’t see the whole list, and built-in rules that fire emails when things change. No Power Automate. No premium connector. No developer.

A spreadsheet in a Teams channel isn’t a tracker. It’s a graveyard with column headers.

Step-by-Step: build a working tracker in ten minutes
Open Lists from the app launcher

Hit the waffle in Microsoft 365, pick Lists, click + New list. You’re at the list creation chooser.

Pick a template, not a blank list

I know — you want to start from scratch. Don’t. Templates ship with sensible columns, conditional formatting, and views already done. Issue tracker and Work progress tracker cover most SMB scenarios. Adjust later.

Save it to a SharePoint site, not “My lists”

The one step everyone gets wrong. My lists is personal storage — the list can’t easily be moved to a team site later. Save it under the SharePoint site behind the relevant Team. Future-you will thank present-you.

Share the form, not the list

Open your new list and click Forms on the toolbar. The list’s own form pops up. Hit Share form, copy the link, send it to your client, your supplier, the new starter — anyone who shouldn’t see the whole pipeline. Their answers land as new rows. They never see the list itself.

Add a rule from the Automate menu

Click Automate > Rules > Create a rule. Pick a trigger — a column changes, a new item is created, an item is deleted, a date approaches. Pick the column, the value, the person to notify. Done. Microsoft’s own guide walks the same path.

When Status changes to Blocked
notify Assigned To

Notice what’s missing? Power Automate. Premium licensing. A developer. Rules cover the boring 80% of automation. Save Power Automate for the genuinely complex 20%.

Pin it as a tab in Teams

In the relevant channel, click + at the top, pick Lists, choose Add an existing list, paste the SharePoint URL. Now the team uses it where they already work. The official Teams guide spells it out.

Why this actually changes behaviour

“I’ll just email it to you.”

That’s the line that kills every SMB tracker. People email instead of logging.

A Lists form sitting on a channel tab fixes that in a way a spreadsheet never will. Anyone clicks + New, fills four fields, presses save. The rule emails the right person automatically. The boss opens the same list and sees everything, in real time, sortable, filterable, with history.

Meet people where they already are.

Lists isn’t there to compete with your project management tool. It’s there to replace the spreadsheet your clients are pretending is one.

If you’re rolling out Microsoft 365 Business Premium and you’re not showing clients this, you’re leaving value on the table they already paid for.

A Cleaner Way to Connect PowerShell to SharePoint Online

image

Connect-PnPOnline with a browser sign-in is fine when you’re sitting at the keyboard. It becomes a problem the moment you’re not. The script that worked beautifully on your laptop refuses to run unattended. The scheduled job that was meant to tidy up orphaned sites overnight quietly does nothing, because it’s still waiting for someone to type a password. And the moment conditional access tightens on the admin account you’ve been quietly using for automation, every script that touches SharePoint behaves like it’s been thrown out a window.

The fix has existed. The setup hasn’t.

Certificate-based app authentication for SharePoint Online has been supported by Microsoft for years. The mechanics are well documented. The trouble has always been the assembly — generate a cert, export the public key, register an app in Entra ID, paste the right GUIDs in the right boxes, find Sites.FullControl.All in the API permissions list, grant admin consent, copy the thumbprint somewhere you won’t lose it, and verify the tenant ID in three different places along the way. By the time you’ve finished, you’ve forgotten which client you were doing it for.

So I’ve written a script that does the whole sequence end to end:

  • Generates a self-signed RSA-2048 certificate in your local certificate store

  • Creates the Entra ID app registration

  • Uploads the certificate and grants Sites.FullControl.All with admin consent

  • Provisions the service principal and adds Application.Read.All on Graph so the app can read its own metadata back

  • Resolves your tenant’s SharePoint root URL automatically from the Graph verified-domains call

  • Saves tenant, app ID, site URL, and thumbprint into a JSON profile so future connections need almost no parameters

What’s normally half an hour of clicking between Entra, the SharePoint admin centre, and a Notepad full of half-remembered GUIDs runs in about ninety seconds.

I’ve been written a new script — https://github.com/directorcia/Office365/blob/master/o365-connect-pnp-cert.ps1

with full documentation here – https://github.com/directorcia/Office365/wiki/Connect-to-SharePoint-Online-with-Certificates

What the Script Actually Does

There are two modes, controlled by switches.

-GenerateLocalCertificate creates a self-signed RSA-2048 certificate in your current user’s certificate store, exports the public key as a .cer file, and optionally exports a password-protected .pfx. By default it’s valid for two years. That’s the local side of the handshake.

-UseCertificateAuth is the everyday mode. You tell it which tenant to connect to — or let it look up the details in a profile map file — and it signs into Exchange Online using that certificate. No password. No browser. No MFA dialog.

The clever bit is the third option: combining -GenerateLocalCertificate with -ProvisionEntraApp -Tenant 'contoso.onmicrosoft.com'. In a single run, the script will generate the local certificate, authenticate to Microsoft Graph via a device-code flow, create the Entra ID app registration if it doesn’t exist, upload the certificate, grant Exchange.ManageAsApp and Application.Read.All with admin consent, create the matching service principal, sign you into Exchange Online to add the app to the Organization Management role group, and save the tenant, app ID, and certificate thumbprint to a JSON profile file so future connections don’t need any of those parameters.

Getting Started

If you’re new to certificate auth, the first run is the one that matters. Drop the script onto an admin machine, open PowerShell, and run:

.\o365-connect-pnp-cert.ps1 -GenerateLocalCertificate -ProvisionEntraApp -Tenant 'yourtenant.onmicrosoft.com'

You’ll be prompted to sign in — via device code for the Graph permissions (which if you use the –copydevicecodetoclipboard, option will put the required device code straight into the clipboard to paste into the request). You need a Global Admin account.

Where this earns its keep across a client base

After that first run, connecting to a tenant looks like this:

.\o365-connect-pnp-cert.ps1 -UseCertificateAuth -Tenant ‘contoso.onmicrosoft.com’

No password. No browser. No MFA prompt. The profile file is the bit that pays you back across an MSP book. One script lives in your tooling folder, each client has its own certificate and entry in the JSON map, and Task Scheduler can finally drive things like site collection audits, sharing reports, lifecycle cleanup on Teams-connected sites, and external-user reviews without anyone watching it run. Filter by tenant or site URL on the command line and the same script services twenty different customers without you ever editing it.

One honest caveat

When you’ve just provisioned a brand-new app, give Entra fifteen to thirty minutes for the role grants to replicate before your first cert-based connect. It’s the single most common reason a fresh setup looks broken when it isn’t. The script flags this on the way out, but it’s worth saying twice.

Why Certificates Beat Passwords

The security argument is the easy one. A certificate’s private key never leaves the machine that generated it. Nothing crosses the wire that an attacker could intercept and replay. There’s no shared secret to rotate across a team, no admin password sitting in a vault that someone might extract, and no MFA bypass to engineer because the flow doesn’t involve a user account at all.

If the certificate is ever compromised, you remove the key credential from the app registration and the access is gone — no password reset required, no impact on any human admin account.

The script enforces TLS 1.2, refuses to assign RBAC if the PnP session has landed in the wrong tenant, warns when the certificate is within thirty days of expiry, and keeps the device-code value off the clipboard by default to avoid leaks on RDP or shared sessions.

The change is a quiet one. You stop thinking about who is signing in and start thinking about which certificate is presenting itself. Once your SharePoint automation is no longer at the mercy of someone else’s MFA settings or a password rotation policy, the kind of work you’re willing to schedule expands. That’s the real win — not the ninety seconds saved on setup, but the chores you finally get around to doing.