Sign in Subscribe

Salesforce Revenue Management (formerly Revenue Cloud Advanced): Exactly When to Refresh — and How to Automate It

Rahul Singh

Rahul Singh

— 7 min read
Salesforce Revenue Management (formerly Revenue Cloud Advanced): Exactly When to Refresh — and How to Automate It

TL;DR

Don’t smash “refresh all.” Refresh only what’s impacted, and add a light automation so Decision Tables, the Product Index, and Pricing data stay in sync with ERP/PLM changes—without burning admin time.

Why this matters

Revenue Management powers fast product search, qualification, and pricing. Those outcomes depend on three living layers:

  • Decision Tables — smart lookups your procedures read.
  • Product Index — the runtime search index behind the catalog.
  • Pricing data — the lookup tables and recipes your Pricing Procedures use to calculate prices.

If the inputs/rules or searchable configuration change, you must refresh the right layer—or UI search goes stale and prices/rules misfire. Salesforce guidance is explicit:

  • Refresh a Decision Table when the object or custom metadata holding its rules changes.
  • Rebuild the Product Index when you add/remove products, change product info, or change search options; the existing index stays live during rebuild and the system switches to the new one after completion.
  • Sync Pricing Data regularly to ensure lookup tables used by Salesforce Pricing reflect the latest values.

The good news: you can automate all three with Flow, Apex, and Connect REST.

What to refresh (and when)

A) Decision Tables (pricing & qualification logic)

Refresh when the table’s inputs or rules change—e.g., a lookup row the table reads, a custom‑metadata flag, or an attribute the table evaluates.

Salesforce says : if you update the object or custom metadata that contain the rules, refresh so outcomes use the latest rules.

Automate it via the Decision Table Refresh Action (invocable) from Record‑Triggered Flow, Scheduled Flow, or Apex.

B) Product Index (Product Catalog Management)

Rebuild when searchable or faceted fields/attributes change, when you add or remove products, or when you update search options.

During rebuild, the existing index continues to serve users; the new index takes over once complete.
Use incremental rebuilds for day-to-day updates — they’re faster and lighter.

Automate it: Use the Connect REST API endpoint:

POST /services/data/v{version}/connect/pcm/index/deploy

Include:

{
"snapshotId": "<runtime_snapshot_id>",
"buildType": "INCREMENTAL"
}

The Snapshot resource is available from API v62.0, and the Deploy endpoint from v63.0+.

C) Pricing refresh (Salesforce Pricing)

Your Pricing Procedures read from internal lookup tables (for list prices, rules, tiers, derived pricing inputs, etc.). Sync Pricing Data on a cadence or after upstream changes so those tables reflect the latest values—and your quotes/orders price correctly. You can sync from Setup or via API.

Additionally, at the quote/order layer you can reprice on demand: enable Instant Pricing, rely on save‑time recalculation, or expose a “Reprice/Refresh Prices” action that calls the underlying APIs.

How to detect when a refresh is needed (Flow triggers)

Use record‑triggered Flows (after save) on the objects that actually matter. Compare $Record vs $Record__Prior to detect changes, then enqueue a refresh (debounced pattern below).

  • Product (Product2): fields you included in index/facets (Family, Category, IsActive, searchable/facet flags).
  • Product Attribute Value: attribute values marked Searchable/Filterable.
  • Product–Category junction: inserts/deletes affect browse and search.
  • Lookup rows read by a Decision Table (e.g., a pricing matrix/custom object).
  • Pricing: when you update price lists/tiers/derived pricing inputs, enqueue a Pricing Data Sync instead of manually visiting Setup.

“Config” edits that don’t fire Flows (e.g., facet changes) can raise a tiny “Search Config Change” record; a simple Flow can react to that and enqueue an Index rebuild.

Avoid over‑refreshing: the debounce queue

Create a RefreshQueue__c object:

  • Type (Picklist): DecisionTable, Index, Pricing
  • ScopeKey (Text): the table API name, RUNTIME_CATALOG, or GLOBAL_PRICING
  • Status: Queued / Done
  • RequestedAt: DateTime

Pattern

  1. Record‑triggered Flows upsert one row per Type + ScopeKey (so 100 upstream edits become 1 queue item).
  2. A Scheduled Flow (e.g., every 15–30 min) reads queued rows, dedupes, executes the correct action(s), then marks them Done:
    • Decision Tables: call Decision Table Refresh Action.
    • Product Index: POST snapshot deploy (incremental by default; full for big refactors).
    • Pricing: call Sync Pricing Data (API) or the admin‑facing Sync action in Setup (see below).

This converts bursts of changes into one refresh per window and keeps you under org/API limits.

How to automate each layer

1) Decision Tables (no custom HTTP needed)

  • Use Salesforce’s built-in invocable “Decision Table Refresh Action” in Flows or Apex. No HTTP callouts needed. You can refresh one or multiple active tables asynchronously.

2) Product Index (Connect REST)

Endpoint (programmatic rebuild):
POST /services/data/v{version}/connect/pcm/index/deploy
Pass the snapshotId and choose INCREMENTAL or FULL. (API v63.0+; snapshot is v62.0+.)

Flow approach (no code):

  1. Named Credential to your org.
  2. Flow → Send HTTP Request:
    • GET /services/data/v65.0/connect/pcm/snapshots → pick snapshotId.
    • POST /services/data/v65.0/connect/pcm/index/deploy with:{"snapshotId":"<ID>", "buildType":"INCREMENTAL"}
    • (Optional) Poll GET /services/data/v65.0/connect/pcm/snapshots/<ID>/index for status; review errors via .../index/errors.

Apex outline (Queueable): same two calls (GET snapshots → POST deploy).

3) Pricing refresh (Salesforce Pricing)

A) Keep lookup tables current

  • From Setup (clicks): Setup → Salesforce Pricing Setup → Sync Pricing Data → Sync. (Ensures the latest pricing values flow into the lookup tables used by Pricing Procedures/decision tables.)
  • Via API (automation): Pricing Data Sync (GET) resource in the Revenue Cloud Developer Guide; use it in a Scheduled Flow or Apex after your price/contract imports.
Think of Pricing Data Sync as the pricing layer’s equivalent of “refresh”—it pushes source‑of‑truth values into the runtime lookup tables so pricing calculations use the latest data.

B) Recalculate prices on quotes & orders (transaction layer)

  • Instant Pricing: automatically recalculates as reps edit.
  • Save‑time pricing: recalculates on save.
  • “Reprice/Refresh Prices” action: expose a button that calls the Place Quote/Order APIs to refresh prices on demand.
  • (For classic CPQ orgs) there’s also a Refresh Prices action that pulls latest PBE values and recalculates lines.
Admin note: you can manage the price refresh notification banner behavior in Transaction Management settings.

A practical pattern (summary)

ERP/PLM/Price updates → Integration upserts
└─▶ Record-Triggered Flows on Product, Attribute, Category, Pricing data
└─ if indexed/faceted/pricing fields changed
└─ Upsert RefreshQueue__c (Type = Index | DecisionTable | Pricing)
└─ Scheduled Flow (every 15–30 min)
├─ Type = Index → POST /connect/pcm/index/deploy
├─ Type = DecisionTable → Refresh Decision Table
└─ Type = Pricing → Run Pricing Data Sync

  • Index stays live during a rebuild and swaps after completion.
  • Prefer INCREMENTAL index builds day‑to‑day; reserve FULL for schema/search‑config overhauls.
  • Sync Pricing Data after price/contract/recipe changes or on a nightly schedule.

Observability & guardrails

  • Status & errors: poll snapshot index status and fetch index errors when builds fail; alert via Slack/Email. (PCM Index info & errors endpoints are documented with snapshot deploy.)
  • Rate/limits: always debounce via the queue so bursts of edits become one refresh per window.
  • Config drift: if you patch Index Settings (facets/fields) with automation, version the change and release in a window.

FAQ

Do Price Book / PBE changes force an index rebuild?
Usually no—PCM indexing centers on Product fields and Attributes configured as searchable/faceted. Rebuild only if price‑related fields are part of your index/facet configuration. (Pricing itself should be handled via Pricing Data Sync and transaction repricing.)

Which API versions should I use?

  • Index deploy is v63.0+ (snapshot is v62.0+). Use your org’s latest (e.g., v65).
  • Decision Table Refresh Action is available as an invocable action (use from Flow/Apex).
  • Pricing Data Sync is documented under Salesforce Pricing Business APIs.

Can I run hourly incremental index builds and weekly full?
Yes—common pattern: incremental after integration windows, full on release weekends; Pricing Data Sync can run nightly (or post‑load).

Sources (key docs)

Final Thought

Smart automation keeps your quotes and catalogs accurate, your admins happy, and your org faster.
Refresh intelligently — not endlessly.

Read more