| name | integration-procedure-cacheable-patterns |
| description | Use when designing Integration Procedures (IPs) with platform cache to cut latency and callout load. Covers cache key design, TTL selection, per-user vs org-wide partitions, invalidation on data changes, and safe fallback on cache miss/stale. Does NOT cover general IP authoring (see omnistudio-error-handling-patterns) or LWC client-side caching. |
| category | omnistudio |
| salesforce-version | Spring '25+ |
| well-architected-pillars | ["Performance","Scalability","Reliability"] |
| triggers | ["integration procedure cache","ip cacheable action","omnistudio platform cache","cache key design integration procedure","invalidate ip cache record change"] |
| tags | ["omnistudio","integration-procedure","cache","performance","platform-cache"] |
| inputs | ["IP whose result repeats across calls","Data volatility of the source","Audience scope (per-user, per-org, per-tenant)"] |
| outputs | ["Cache key + TTL design","Partition selection (org-wide vs session)","Invalidation plan","Fallback behavior when cache is unavailable"] |
| dependencies | [] |
| version | 1.0.0 |
| author | Pranav Nagrecha |
| updated | 2026-04-23T00:00:00.000Z |
Integration Procedure Cacheable Patterns
Purpose
Integration Procedures are the workhorse for orchestrating DataRaptors
and external callouts in OmniStudio. Many IPs return mostly-static data —
product catalogs, entitlement matrices, rate tables — that is re-fetched
on every UI load. Platform Cache inside an IP cuts latency and callout
volume by orders of magnitude, but only if the cache key, TTL, partition,
and invalidation are designed together. Teams either skip caching (slow)
or cache too aggressively (stale data, cross-user leakage). This skill
codifies the decisions.
When To Use
- IP response is largely stable within minutes / hours and is fetched
repeatedly.
- IP triggers external callouts that bill per-call or have quotas.
- User-page TTFB is dominated by an IP hop.
- Multiple components / flows call the same IP with the same inputs.
Recommended Workflow
- Measure. Log IP latency and call volume. Cacheability is a
decision, not a reflex — some IPs shouldn't be cached.
- Design cache key. Include every input that changes the result AND
nothing that doesn't. Stable ordering matters.
- Pick partition. Org-wide for shared data (catalogs, metadata),
Session for per-user data (entitlements when scoped to the user).
- Choose TTL. Align TTL to source-data SLA. Default 5-15 minutes for
quick wins; longer needs explicit invalidation.
- Design invalidation. Record-triggered flow or Apex trigger on the
source object purges cache keys when data changes.
- Plan fallback. Cache unavailable (partition full, platform error)
must not break the IP. Fall through to live fetch.
- Monitor cache hit ratio. < 40% suggests wrong key or wrong TTL.
Cache Key Design
- Include: inputs that change the result, the API version, and the
feature flag set that governs behavior.
- Exclude: request ids, timestamps, user-identity if the result is
org-wide.
- Keep keys short but unambiguous; platform cache has key-length limits.
Example key: ip:PricingMatrix:v3:sku=ABC123:region=NA:tier=GOLD
Partition Selection
| Partition | Scope | Use For |
|---|
| Org-wide | All users | Catalogs, reference data |
| Session | Per user | Entitlements, personalized results |
Do NOT put user-specific data in the org-wide partition. Data leaks.
