Microsoft 365 & Copilot
Copilot That Respects Your Permissions Model
Microsoft 365 Copilot only works as well as the permissions and content underneath it. Webcoda has built SharePoint intranets for NSW Health, Infrastructure NSW and other enterprise and government clients, so before we touch Copilot we already know how a real permissions model behaves in production.
Who this is for
Copilot is licensed and barely used
IT is worried about oversharing
Leadership wants adoption without an incident
What we deliver
-
01
A permissions and content audit before rollout
Where inheritance is broken, which sites are effectively public internally, and which content is stale enough to be dangerous when quoted back as current.
-
02
A scoped pilot group
One team, real work, measured. Enough to learn what your staff actually ask Copilot before the whole organisation asks it.
-
03
Copilot-ready labelling and access review
Sensitivity labelling and access cleanup on the content Copilot will reach, prioritised by exposure rather than alphabetically.
-
04
Custom agents and plugins where the product is not enough
When the out-of-the-box answer is wrong because the data lives somewhere Copilot cannot see, we connect it properly.
-
05
Adoption training that survives the launch week
Short, role-specific, and built around the tasks the pilot showed people actually do.
Copilot surfaces whatever a user already has access to. Any oversharing that sat quietly for years becomes visible and actionable on the day Copilot goes live. Nothing new leaked. It just got a search box.
Why permissions come first
Most Copilot projects that go badly do not fail on the AI. They fail because a decade of ad hoc SharePoint permissions was never meant to be queried in natural language by everyone at once.
Every competitor in this market approaches Copilot from licensing and governance. We approach it from having built the intranet the permissions live in, which is a different starting point and a faster one.
The practical order
Audit the permissions. Fix what the audit finds. Pilot with one team. Then roll out. Turning Copilot on first and auditing afterwards is the same work in the wrong order, with an incident in the middle.
How an engagement runs
-
Step 01
Assess
Permissions and content audit. What Copilot would be able to reach today, which of that should not be reachable, and which of it is out of date.
-
Step 02
Prototype
One pilot group, doing real work. We watch what people ask, where the answers are wrong, and why. Usually the answer is content, not the model.
-
Step 03
Integrate
Rollout with governance already in place. Labelling, access review and monitoring shipped before the licences are widened, not after.
-
Step 04
Scale
Organisation-wide adoption, with someone owning it. Role-based training, a review cadence, and a named owner for the content Copilot depends on.
Honest scoping
Starts with the audit
Then a pilot
Licences are yours
Copilot, answered
Copilot does not grant new access. It surfaces what a user could already reach, which in practice means long-standing oversharing becomes findable. That is why the permissions audit comes before the rollout.
You need a permissions and content review. Whether you call it readiness matters less than doing it before the licences go wide, because the alternative is finding out through a complaint.
Yes, and that is where most of the useful custom work sits: agents scoped to a particular site, library or process, with the permissions and source content deliberately chosen rather than inherited.
Not under the Microsoft 365 Copilot terms as they stand. We will show you the specific data boundary that applies to your tenancy rather than paraphrasing it.
Talk to us about Copilot
Thirty minutes on your current setup, honestly assessed.
