I am having an issue with keeping AppConnect and our CRM contact data in sync. When you edit a contact in your CRM — change a phone number, fix a misspelled name, create a new client record, the App Connect panel doesn't pick it up. Reps see stale data on the next inbound call. The only way to refresh is the manual "Refresh Contact" button. F
What I’ve found in looking at the documentation is that the server-side cache is AccountDataModel, keyed by (rcAccountId, platformName, contact-<phoneNumber>).. Verified directly:
- No TTL. models/accountDataModel.js defines exactly four fields: rcAccountId, platformName, dataKey, data. No expiry, no ttl, no purge-on-updatedAt. Rows are immortal.
- No sweeper. lib/cacheCleanup.js is 13 lines and only destroys CacheModel rows where expiry <= now. No AccountDataModel reference. No setInterval/cron/node-schedule anywhere in packages/core either.
- createContact doesn't invalidate. handlers/contact.js#L149-L201 has zero references to AccountDataModel. So when you create a new client through the panel, the previously-cached "unknown caller" row for that phone is still served on the next call.
- One invalidation path, gated on a query flag. handlers/contact.js#L21-L37 short-circuits unless isForceRefreshAccountData === true is in the URL. Only the manual Refresh Contact button sends it. Even with the flag set, the row is only destroyed when the platform returns zero matches (line 109); otherwise it's updated (line 90) — either way, force-refresh is the only entry.
One potential bandaid I’m looking at is to build a small Lambda that fires GET /contact?phoneNumber=…&isForceRefreshAccountData=true from a CRM-side webhook on every relevant edit (Client name + phone field changes, new Client creation), but I wanted verification from the team that the endpoint would work for this purpose.Since we have control over our CRM (QuickBase) and our adapter, we built write-side invalidation instead of waiting on a read-side fix. The idea: every time the CRM record changes in a way the panel cares about, we push a force-refresh to App Connect from the backend, so the cache row is rewritten before the next inbound call ever reads it.
