Working with the SharePoint Term Store

What each action really does — and when to use it

If you work with metadata in Microsoft SharePoint, you will eventually run into this situation:

“We need to clean up the Term Store… but what does each option actually do?”

The Term Store looks simple.
The impact of the wrong click is not.

This post explains every action you see in the Term Store menu, why it exists, and when you should (or should not) use it.

No theory. Just real-world guidance.

First: why the Term Store needs governance

The Term Store is not a list of labels.
It is a shared dependency used by:

• Libraries and lists
• Views and filters
• Search refiners
• Power Automate flows
• Copilot and AI retrieval

A change here affects every site that consumes that term.

That’s why understanding intent matters more than knowing where to click.

How the Term Store is structured (quick refresher)

You always work within this hierarchy:

• Term group – ownership boundary (often per domain or solution)
• Term set – logical collection (Country, Document Type, Department)
• Term – the value users select

Most actions happen at term level, so that’s where things usually go wrong.

Term actions explained (why → when → risk)

Add term

Why it exists
To introduce a new, controlled value instead of free text.

Use it when

• A new business concept is officially introduced
• The value will be reused across multiple sites

Governance note

• Low risk
• Naming conventions matter more than the click itself

Rename term

Why it exists
Names change. IDs should not.

What actually happens

• Term ID stays the same
• Existing content is not broken
• Only the label changes

Use it when

• Fixing spelling
• Business naming changes

Intent
Rename is almost always safer than delete + recreate.

Move term

Why it exists
Taxonomies evolve. Structures improve over time.

What happens

• Term ID stays the same
• Existing metadata remains valid
• Search, filters, and flows keep working

Use it when

• Reorganising the hierarchy
• Fixing earlier structural decisions

Best practice
Move instead of rebuilding.

Copy term

Why it exists
To create a similar term elsewhere, without linking it.

What to know

• New term ID
• No relationship to the original

Use it when

• You need a starting point, not shared behavior

Trade-off
Easy copy, but no shared governance.

Copy term with children

Why it exists
To duplicate a full hierarchy quickly.

Use it when

• Bootstrapping a new taxonomy
• Creating a parallel structure

Governance note

• Still creates new IDs
• You now own two independent trees

Pin term

Why it exists
To expose the same term in multiple places.

What actually happens

• One term ID
• One source of truth
• Multiple entry points

Use it when

• One value must appear in multiple term sets

Risk
Changes affect all pinned locations.

Reuse term

Why it exists
Same intent as pinning: reuse without duplication.

Key point

• Same ID
• Shared lifecycle
• Central ownership required

Good for
Enterprise-wide reference data (countries, legal entities).

Merge term

Why it exists
To fix past mistakes without breaking content.

What happens

• Existing content is reassigned
• Duplicate term disappears
• One clean value remains

Use it when

• You discover duplicates
• Naming drift already happened

Governance note
This is controlled cleanup — communicate before using.

Deprecate term (most important)

Why it exists
Because deleting history is usually the wrong move.

What happens

• Existing documents keep the value
• Users cannot select it anymore
• Search and Copilot still understand it

Use it when

• A term should no longer be used going forward
• A replacement exists
• History still matters

Rule of thumb
If it was ever used → deprecate, don’t delete.

Delete term

Why it exists
For mistakes — not lifecycle management.

What actually happens

• Term disappears from the taxonomy
• Existing content becomes orphaned
• Views, filters, flows, and search may break

Use only when

• Term was created by mistake
• Term was never used
• Cleaning test or demo data

Risk level
High.

Quick decision table (consultant version)

Clear takeaway

The Term Store is not about clicks.
It’s about lifecycle decisions.

• Create deliberately
• Move instead of rebuild
• Deprecate instead of delete
• Remove only when you’re sure nothing depends on it

That’s how you keep metadata:

• Stable
• Searchable
• Automation-safe
• AI-ready