Summary

Live Salesforce was opened and inspected after Sam asked whether the issue had been pulled up in Salesforce directly. The record inspected was MAT-26010866017, Matter Makenna Garvey | 1/6/2026 | Automobile Accident, at the RingCentral tab.

What was accomplished

• Verified live Salesforce access and opened the real Matter UI, not only metadata.
• Confirmed the RingCentral tab renders an iframe area and Sign In button.
• Clicked Sign In from the live/browser context and reproduced the staff-facing RingCentral OAuth error.
• Confirmed the OAuth URL still included client_id=40vRKrMiQIsaowVS0lBnSK, which is the Salesforce label value tied to the RingCentral SMS Quick Start App.
• Confirmed via live Tooling API readback that the deployed LWC source no longer imports RingCentral_Embeddable_Client_Id, no longer includes clientId= in the iframe URL, and still sets History as the default workspace.
• Ran a clean browser-profile QA against https://apps.ringcentral.com/integration/ringcentral-embeddable/latest/app.html?enableSMSTemplate=1&enableSmsSettingEvent=1. In the clean profile, RingCentral reached normal login and used default client ID SlwZwfZ_STmpq2W_qOaC5A, not the bad 40vRKr... ID.

Current diagnosis

This is not Janelle lacking Salesforce permissions and not staff user error. Janelle has RingCentral_Panel_User, and the iframe appears in Salesforce. The sign-in failure comes from RingCentral OAuth configuration and stale client-side state. The active bad client ID belongs to a RingCentral app configured for JWT auth/no redirect URI, so the browser authorization-code flow throws OAU-113.

The Salesforce source deploy is live, but the browser/Salesforce session inspected is still behaving like an old compiled client. The UI also still visually showed Summaries first/default during inspection even though the live source says History first/default. That strongly suggests Salesforce Lightning/browser cache or RingCentral embeddable storage still needs clearing, or a clean session must be tested.

Handoff

Next agent can continue from the Salesforce metadata project at /Users/samaguiar/Documents/Projects/Repos/sail-litify/Litify_AI_Integration_Project/salesforce-metadata. Useful proof points: dry-run deploy 0AfUV000001X7gT0AS, live deploy 0AfUV000001X7i50AC, and live Tooling API readback for LightningComponentResource on litifyRingCentralPanel.

Suggested next steps are practical, not mandatory: first verify from a clean Salesforce browser session or clear site/storage cache and reload the Matter tab. If staff still hit OAU-113, create or configure a proper RingCentral 3-legged OAuth browser app with redirect URI https://apps.ringcentral.com/integration/ringcentral-embeddable/latest/redirect.html, then update the Salesforce label/component to use that registered app. Do not convert the existing JWT app without checking what uses it.

Reason for ending

The immediate user question was whether live Salesforce had actually been opened and inspected. It has now been inspected directly. Follow-up remains open because the source fix is deployed but the current browser session still reproduced the stale OAuth path.

Status

Needs follow-up. Priority high because staff sign-in is blocked.