Chapters: 
O365 Plumbing

Status CHECK

F12

  1. Open DevTools → Network.
  2. Clear the log.
  3. Filter to Fetch/XHR.
  4. Add one disposable term, say Dino.
  5. Press Enter and wait for it to disappear.
  6. Look specifically for a request that is red, returns 401 / 403 / 409 / 400 / 500, or returns 200 but contains an error payload.

What we want is not yet “how do we hack the API.” We just want to identify what SharePoint attempted and what the service answered.

That gives us a very useful fork: 

POST attempted
├── 401/403 → permissions / token / role propagation
├── 400/409 → object/configuration/validation problem
├── 5xx     → SharePoint service/backend problem
├── 2xx + error-ish response → UI/API contract weirdness
└── no POST at all → client-side/admin UI failure

Microsoft Graph’s documented create-term operation is a POST to the term store set’s /children endpoint, and it requires delegated TermStore.ReadWrite.All if you call it through Graph directly. (Microsoft Learn) But we do not need Graph permissions yet. The SharePoint admin UI may be using a different internal endpoint anyway.

One correction to my previous wandering around term-set tests: since you’ve already established “copy works, create does not” at both term and set level, I would stop spending experiments on the taxonomy tree itself. You’ve tested that axis enough.

Your next evidence should come from the wire.

And because the Contributor assignment happened today, I would save the Network trace if it fails, then retry the exact same operation tomorrow. If tomorrow’s POST suddenly succeeds without any other change, you’ve caught propagation red-handed. If it still fails, the HTTP response should give us something concrete to pursue.

That’s a much better next move than requesting Azure access prematurely.

If you see 401/403, permissions or token state stays high on the list. 400/409 points more toward validation or taxonomy object state. 5xx pushes suspicion toward SharePoint’s backend. And if there is no failing request at all, the admin UI itself may be swallowing the operation before it ever leaves the browser.

  1. Open the Term Store in SharePoint Admin.
  2. F12 → Network → Fetch/XHR.
  3. Clear the network log.
  4. Try to add Fred.
  5. Look at the request generated at that exact moment.
  6. Open it and inspect:
    • Request URL
    • Request method
    • Status code
    • Response body
    • optionally the Authorization header presence, but do not copy or share the bearer token itself.

What I especially want to discover is whether the UI is calling: 

graph.microsoft.com/...

or some SharePoint-specific endpoint such as: 

<tenant>-admin.sharepoint.com/...

That distinction tells us which plumbing is actually failing.

If we see something resembling: 

POST .../termStore/sets/<GUID>/children
403 Forbidden

then we have a beautifully precise result: the UI attempted a real create, but authorization rejected it.

If it is 400, we inspect the response because SharePoint may be rejecting the object rather than your authority.

If it is 200 OK       
         201 'created' 

Microsoft documents creating an entire Term Store group using the same delegated permission, TermStore.ReadWrite.All, although the signed-in user's Term Store role still determines what they can actually administer. (Microsoft Learn)

 

term store