Custom field syncs and 24-hour cache behavior

Short Description When integrations populate Hive9's custom fields, the data is cached. This article explains the cache windows and what to do when source-side changes don't appear fast enough.

What this article answers

Why integrations don't update Hive9 instantly.
The two cache layers and their refresh windows.
How to force a refresh.

Why caching exists

Hive9 caches integration-sourced data to keep the application responsive. Live integration fetches on every dropdown render would slow the application substantially, especially in instances with many custom attributes and large picklists.

The tradeoff: source-side changes don't appear in Hive9 immediately. They flow in on a refresh cycle.

The two cache layers

Layer 1 — Business unit / master data

Time-sensitive lookup data like Business Units, Cost Centers, Product Lines.

Refresh window: up to 24 hours.
Behavior: changes in the source system propagate within the window.
Cannot be forced from the customer-side UI — admin or Support can clear if needed.

Layer 2 — Custom field options

Picklist values populated via integration (e.g., Business Group / Business Product options synced from your CRM).

Refresh window: separate cache, may need an explicit clear.
Behavior: values removed from the source can linger in Hive9 dropdowns until the cache is cleared.

What you'll see as a user

When the source system has updated but the Hive9 cache hasn't refreshed:

Removed picklist options still appear in dropdowns.
New options aren't yet available for selection.
Changes to value labels (renamed options) show the old name.

This isn't a bug — it's the expected gap during the refresh window.

What you'll see as a customer admin

If users report stale data:

Confirm the source-side change actually saved. Open the source system; verify the change.
Check the timing. If less than 24 hours have passed, wait.
If beyond the refresh window, request a cache clear via contact Support with:
- The custom attribute name.
- The specific value(s) to remove or update.
- The source system that owns the value.
- The date and time the source-side change was made.

Support clears the cache; Hive9 then pulls fresh values from the source.

Source-system caveats

Source systems vary in how they signal changes:

Some explicitly send an "obsolete" flag (Hive9 hides those values on next refresh).
Some simply omit obsolete values from the data feed (Hive9 keeps the value until cache clear or until you reconcile).

Talk with your CSM about how your source system handles obsolescence — it affects the integration design.

What this means for downstream tactics

Cache clears affect new selections. Existing tactics that already use an obsolete value continue to display it:

The value remains visible on the tactic Inspection Window.
The tactic continues to function normally.
Reports filtered on the obsolete value still surface the historical tactics.

If you need to remove obsolete values from existing tactics:

Filter the Plan Grid to find tactics with the value.
Update each tactic individually, or use Honeycomb Bulk Actions for many.
Verify via the audit log.

Common questions

Why does Hive9 cache at all? Performance. Without caching, dropdowns would be slow, especially in large instances. The 24-hour refresh balances responsiveness with data freshness.

Can I make my refresh faster? For one-off needs, Support can clear a cache. For ongoing faster refresh, talk with your CSM about integration design — some integrations support more frequent refresh cycles.

Will an obsolete value cause errors? Not directly — Hive9 accepts an obsolete value on existing tactics. Trying to save a tactic with a recently-obsolete value can sometimes fail because the validation layer rejects it. See Picklist option still shows after being marked obsolete in source system.

Does the cache cover all integration data? Most. Some real-time integrations (e.g., transactional invoice pushes) bypass the picklist cache because they're event-driven rather than dropdown-driven.