Sam reported that the RingCentral Matter tab looked good, but a desktop staff test hit a failure after the employee opened RingCentral, logged in, and clicked a button. I treated this as a live Litify/RingCentral debug lane and patched the likely desktop timing defect.
The desktop RingCentral panel keeps the iframe loaded in the background, but litifyRingCentralPanel.js reset frameLoaded to false when the user switched from Summaries into Call/SMS/History. Since the iframe was already loaded, it might not fire onload again. That means the pending Call/SMS/History command could be skipped, which matches the staff report: login succeeded, then a button action failed.
Patched litifyRingCentralPanel.js so the desktop flow keeps iframe readiness when leaving Summaries, clears stale actions when returning home, and retries the RingCentral postMessage action briefly after the workspace becomes visible. SMS now posts directly through rc-adapter-new-sms with conversation: true. The Call action still opens/prepares the softphone call UI rather than immediately auto-dialing.
No SMS Magic records were deleted. SMS Magic was not uninstalled. SMS Magic automation was not disabled. History access was not removed.
Live pre-change retrieve was captured at Repos/sail-litify/Litify_AI_Integration_Project/salesforce-metadata/tmp/ringcentral-desktop-button-fix-2026-05-17/live-retrieve/.
First check-only caught a parse error before production: 0AfUV000001Wusv0AC, failed with LWC1503: Parsing error.
Corrected check-only succeeded: 0AfUV000001WuuX0AS, 0 component errors.
Production deploy succeeded: 0AfUV000001Wuw90AC, 0 component errors.
Post-deploy live verification confirmed litifyRingCentralPanel last modified 2026-05-17T14:42:52.000+0000. Post-deploy retrieve was captured at Repos/sail-litify/Litify_AI_Integration_Project/salesforce-metadata/tmp/ringcentral-desktop-button-fix-2026-05-17/postdeploy-retrieve/, and the retrieved JS matched the local patch except final newline.
Persistent RingCentral login may not be purely a LWC code issue. The next check, if staff still need repeated sign-ins, should focus on RingCentral OAuth/app settings, Salesforce embedded iframe storage/cookie behavior, SSO, and browser privacy policy. The app should persist as much as RingCentral and the browser allow, but embedded third-party app storage can be affected by browser policy.
Continue from the deployed desktop button fix. Have the same staff user retest on desktop: open a Matter, open RingCentral, sign in if prompted, click Call, SMS, and History. Confirm Call opens the softphone call UI with the selected Matter number, SMS opens the client conversation/thread, and History opens RingCentral history. If button behavior is now good but login is not persistent, move into OAuth/SSO/browser-storage investigation rather than changing the button code again.
A. Re-test with the same desktop employee and record exactly which button fails if anything still fails. Recommended because the likely timing bug is patched live and the next useful evidence is real staff/browser behavior.
B. Add a visible RingCentral connected readiness state plus a one-click Sign in button that sends rc-adapter-login if staff are not logged in. Recommended if users still hesitate or click before auth is ready.