Renaming a managed metadata term does not guarantee that its new label immediately appears in a connected Power Automate flow. Microsoft documents a connector limitation for term-set label updates. Check the affected item's data before rebuilding the connection or replacing the taxonomy term.
Use a nonconfidential test item and coordinate with the taxonomy owner. A label change can affect many documents and business rules. This guide focuses on a renamed term's displayed value, rather than missing permissions, a broken connection or a sensitivity label.
Identify exactly what was renamed
Record the column, term set, old label and approved new label. Distinguish a managed metadata term from a Choice column option, a library display name or a sensitivity label. Similar words in the interface can refer to very different features.
The SharePoint connector reference explicitly notes that term-set label updates do not automatically appear in connected flows or apps. Its documented workaround involves directly editing the affected list item to refresh the label.
Compare item data with taxonomy administration
Inspect the term in the approved administration interface and the value on one affected item. Then inspect a new flow run's sanitized output. An old run history remains a record of what that earlier execution received; it should not be expected to rewrite itself after a label change.
Keep identity and display wording distinct
Do not create a replacement term simply to make a different label appear. That can introduce another taxonomy identity and leave documents divided between terms. Ask the taxonomy owner to confirm whether the change was a rename or a deliberate replacement.
Test the documented refresh on one item
With authorization, directly edit the affected test item's metadata through SharePoint and save the intended selection. Use a new controlled flow execution to inspect the returned label afterward. Avoid broad updates across a production library as the first experiment.
Microsoft's term management guidance distinguishes renaming, copying and other taxonomy operations. Confirm the operation performed by the authorized owner. Inspect the value supplied by the item separately from the wording in a later email: changing the message text does not refresh source metadata.
| Where the old wording appears | What to compare |
|---|---|
| Historical run | Value captured at the time of that run |
| New run after item edit | Fresh source output and current label |
| Email built from fixed text | Hard-coded message content |
| Different metadata column | Whether it uses the renamed term at all |

Inspect downstream conditions
A flow may compare a label with a hard-coded string. If the approved wording changes, such a condition can route work incorrectly even after the current label is refreshed. Inventory where the wording is used before changing a shared taxonomy.
Test both sides of the business branch
Use a test item that should match the renamed category and another that should not. Confirm the intended outcome without sending production notices. A successful label refresh is incomplete if the downstream rule still expects the old wording.
Do not replace authorization with a label check
Metadata labels describe content; they do not establish who is permitted to read it. Keep document access and notification recipients governed by the actual security configuration. A renamed category must not accidentally broaden distribution.
Coordinate a small change plan
Have the taxonomy owner, flow owner and document owner agree the new wording and the test. Record whether existing items need a supported refresh and which flows contain label-dependent logic. Do not change all records automatically merely because one sample showed stale text.
The SharePoint metadata guide can help document the column's meaning and ownership. Include approved terminology changes in that governance record so another person does not later reintroduce the old label as a second term.
If the sample still returns unexpected wording after the documented item edit, retain a sanitized run identifier and the relevant column configuration for official support. Do not expose full document contents, authentication details or an entire production response in a public forum.
Accept the change when new runs use the intended item metadata and the dependent conditions behave correctly. Keep historical run values distinguishable from current source data so a past execution is not mistaken for evidence that the refresh failed.

