Salesforce Sync & Cache Audit

This page is the full technical audit of how Forge keeps your Salesforce data in sync — every Salesforce object across Blackthorn's Events, Payments, Fundraising, and Base packages, cross-referenced against what Forge actually caches, how fast, and what to check if something looks like it isn't syncing. It's more detailed than the summary in the Sync & Caching section above — this is the reference version for anyone who wants the full picture, including your own technical/admin team.

How sync & caching actually works

Forge has three structurally distinct read-cache mechanisms, plus one shared write path. None of them are bidirectional — every write goes through a separate path and then (sometimes) explicitly invalidates a cached row.

• A generic, tenant-wide Salesforce-to-Postgres object cache. This is where the large majority of cached objects land (86 of them as of 2026-09-22 — see the table below). It is read-only from Salesforce's perspective — this path never writes back to Salesforce.
• Feature-specific computed-metrics caches (dashboard and pipeline/ROI summaries) — these don't store raw Salesforce records; they run live queries against Salesforce on each refresh and persist a computed summary.
• Short-lived, Redis-only response/lookup caches (event basics, display names, session-meta, related-lists, edit-access) — invalidated explicitly whenever the underlying data is written.
• The write path (Forge to Salesforce): a synchronous path for most writes, and a durable, asynchronous write-through queue for a defined set of objects (mainly Payments, Donations, Fundraising, and Auctions) that's drained by a background reconciler.

Login/session warm-up: whenever a user with a session active in the last 30 days causes Forge to boot up, all 86 cached objects get an incremental sync attempt for that tenant, bounded per-tenant so it can't run indefinitely. This is a tenant-wide warm, not scoped to the person logging in — today it's all-or-nothing across every event and time range for that tenant.

Portal (Contact-authenticated) reads go through a single, strictly read-only chokepoint that re-reads the same cached rows with an owner-field check, so a donor or bidder portal only ever sees their own records.

What's cached, and how fast

Every object below is cached in one shared Postgres table, keyed per tenant and record. Salesforce is always the source of truth — Forge never writes to this cache from a user action, only from sync jobs.

(86 cached objects total as of 2026-09-22. Fundraising settings/config objects (Auction Setting, Donation Settings, and a handful of custom-metadata configuration objects) were deliberately left out of the cache — they're per-org configuration, not per-record data, so there's nothing to sync per record.

Per-event vs. tenant-wide syncing

A subset of objects — Session, Ticket, Form Submission, Sponsor, Speaker, Budget & Expense, Table, Custom Content, Exhibit Space, Exhibit Assignment, Sponsor Benefit, Attendee Group, Discount, Waitlist, Order, Event FAQ, Event Content, and Staff — can also be synced scoped to a single event, on demand. Everything else only syncs tenant-wide, across every event at once.

Not synced — always queried live

These objects are known to Forge but intentionally excluded from the cache system entirely — any screen reading them always queries Salesforce live, never a cache. This is by design, not a sync gap, though it's the first thing to check if a customer reports one of these “not syncing.”

Computed summary caches

Two dashboards don't store raw Salesforce records at all — they run a live query across several objects and persist just the computed summary, refreshing on-demand when the summary looks stale.

Short-lived caches

A handful of small, fast-expiring caches sit in front of specific screens — event basics, display names, session-list results, related-list rows, and edit-permission checks. These exist purely for responsiveness (seconds to a few minutes), not durability, and are cleared automatically whenever the underlying record is written.

How writes reach Salesforce

Most Forge writes go straight to Salesforce synchronously. A defined set of objects — mainly Payments, Donations, Fundraising, and Auctions — instead go through a durable queue: the write is recorded, then a background process executes the real Salesforce write shortly after.

• Payments: Invoice (Sales Document), Transaction, Line Item, Payment Schedule.
• Donations / Fundraising: Donation, Donation Allocation, Donation Soft Credit, Recurring Gift, Pledge, Gift Aid Declaration, P2P Participant, P2P Team, Designation.
• Auctions: Auction Registration, Auction Transaction, Auction Item, Auction Bundle, Auction Appeal, Auction Pledge, Bid, Raffle Entry.
• Events: Attendee, Event, Session Attendee, Attendee Group, Form Submission, Form Submission Answer, Seat, Table.

Full object catalog by package

Cross-referencing every Salesforce object across all four managed packages against cache status. “Not in cache system” does not mean Forge never reads an object — many are queried live outside the tiered cache system, or are pure configuration/metadata objects with no sync concept at all — only that it isn't part of the tiered cache/warm-sync system covered above.

blackthorn-base (bt_base__) — 26 objects

Base package objects (forms infrastructure, visibility rules, translations, scheduling).

events (conference360__) — 119 objects

Events package objects — the largest package, covering the full event/session/attendee/form surface.

fundraising (bt_fundraising__) — 29 objects

Fundraising package objects — donations, auctions, pledges, peer-to-peer.

payments (bt_stripe__) — 64 objects

Payments package objects — invoices, transactions, gateways, subscriptions infrastructure.

forge-unpackaged (org-native custom objects) — 55 objects

These are Forge-owned custom objects with no managed-package namespace (Abstracts, Appointments, Event project-management, Purchase Orders, Vendor tracking, and a few others). None of them participate in the tiered cache/warm-sync system described above — if one of these is expected to sync on login, that would be new work, not a gap in existing wiring.

Likely causes when something looks like it isn't syncing

1. Cold-tier objects have no dedicated refresh cadence — only the 6-hour full sweep and login warm-up touch them, so a record can be stale for up to 6 hours (or effectively longer for a low-traffic tenant that hasn't had a recent session).
2. The handful of “declared, not synced” objects above never populate the cache regardless of time — any screen reading one of these should fall back to a live query and show correct (if slower) data. If it shows nothing instead, that's worth reporting.
3. Write-through lag: a Forge write to a queued object completes asynchronously, and the read side only picks it up on the next tier sync — a few minutes on hot/warm objects, up to 6 hours on cold ones.
4. An unverified cache-key identity (see the Discount/Logistics callout above) can make a sync silently fail or return zero rows every cycle for that specific object.
5. A tenant's session may simply predate an object being added to the cache system — a tenant that hasn't had a fresh full sync since an object was added could still show an empty cache for that object specifically.

If you've checked the above and something still looks wrong, contact support with the specific object and record in question so we can check your org's sync state directly.