A picklist option still appears in Hive9 after it was removed from our source system

Short Description You removed a value from an integrated source system (CRM, BU master, etc.) and it's still showing up in Hive9 picklists. This is a cache-timing behavior — here's the expected refresh window and how to force a refresh if needed.

What this article answers

Why Hive9 doesn't always reflect source-system changes immediately.
The standard refresh windows.
How to escalate if the value still shows after the expected refresh.

What's happening

Your team marked a value as obsolete or deleted it in the system that feeds custom attribute options into Hive9 (for example, your CRM, marketing data warehouse, or business-unit master). Hours later, the value is still appearing in Hive9 dropdowns and selectable on tactics.

Why this happens

Hive9 caches integration data to keep the application responsive. Changes in source systems flow into Hive9 on a refresh cycle, not in real time.

The standard refresh windows are:

Business unit and similar master-data attributes: up to 24 hours.
Custom field options populated via integration: cached separately. After source-side changes, the Hive9 cache may need to be cleared to pick up the change.

Until the cache refreshes, the old value remains visible — and selectable — in dropdowns across the application.

How to handle it

Step 1 — Wait for the standard refresh

If less than 24 hours have passed since the source-side change, the change is likely still propagating. Check again after the 24-hour window.

Step 2 — Verify the source-side change actually saved

Confirm in the source system that the value is deleted or marked obsolete (not just unpublished).
If your integration relies on an obsolete flag, confirm the flag is set correctly. Some integrations only suppress values that are flagged obsolete, not values that have simply been removed.

Step 3 — Request a cache clear

If the value persists beyond the expected refresh window, contact Support with:

The custom attribute name and the specific value you want removed.
The source system that owns the value.
The date and time the source-side change was made.

Support can manually clear the relevant cache so Hive9 picks up the change immediately.

[SCREENSHOT NEEDED — Custom attribute dropdown showing stale value]

Step 4 — Audit downstream impact

Even after the cache clears, existing tactics that already use the obsolete value continue to display it. Removing the option from future selections doesn't strip it from historical records. If you need to remove the value from existing tactics:

Use Filter Panel to find tactics referencing the obsolete value.
Update each tactic to a replacement value individually, or use Honeycomb Bulk Actions to update many at once.
Confirm via the Audit Log that the changes were recorded.

Common questions

Will this break my historical reports? Reports show the value present on the tactic at report time. If you change tactics to a new value, the new value is what shows. Use Snapshots before bulk-editing if you need to preserve a historical view.

Can I prevent the obsolete value from being selected even before the cache clears? Not from the customer-side admin UI. The cache clear is the proper path.

Why does Hive9 cache instead of fetching live? Live integration fetches on every dropdown render would slow the application substantially, especially in instances with many custom attributes and large picklists.