Account Manager banner in Concierge RHP shows blank body text

[MelvinBot]

Bug: Account Manager banner in Concierge RHP shows blank body text

When a user clicks on the persistent Concierge button in New Expensify, if the customer is assigned an Account Manager, the RHP should display a banner at the top of the chat suggesting the customer can reach out to their Account Manager.

Current behavior: The banner appears, but the body text is completely empty.

Expected behavior: The banner should display text identifying the Account Manager and suggesting the customer can reach out to them.

Slack thread: https://expensify.slack.com/archives/C0AN979CQ8H/p1776873664031239

[Valforte]

@MelvinBot investigate this issue and give me root cause analysis and potential solution

[MelvinBot]

Proposal

What is the root cause of that problem?

The banner renders before the account manager's personal details have loaded from Onyx, causing the body text to be an empty string.

In AccountManagerBanner.tsx:33-35, the visibility guard only checks accountManagerReportID, whether it's a Concierge chat, and local dismiss state — it does not check whether the text content resolved to a non-empty string.

The text is built on line 38:

const chatWithAccountManagerText = displayName && login ? translate('common.chatWithAccountManager', ...) : '';

There are three chained Onyx lookups (ACCOUNT_MANAGER_REPORT_ID → account manager Report → PERSONAL_DETAILS_LIST). If any intermediate value hasn't loaded yet, participantPersonalDetail is undefined, so login is undefined and the text falls back to ''. The Banner component (Banner.tsx:108) skips rendering when text is falsy, but the banner container, icon, close button, and "Chat now" button all still render — producing a banner with blank body text.

If the personal details never load (e.g. the account manager's accountID resolves to DEFAULT_MISSING_ID because the report has no participants), the text stays blank permanently.

What changes do you think we should make in order to solve the problem?

Add chatWithAccountManagerText to the early-return guard in AccountManagerBanner.tsx so the banner is hidden when the text is empty. Update the guard on line 33 to:

if (!accountManagerReportID || !isConciergeChatReport(report) || !isBannerVisible || !chatWithAccountManagerText) {
    return null;
}

This requires moving the displayName/login/chatWithAccountManagerText computation above the guard (lines 36-38 moved before line 33). Once the personal details load, Onyx triggers a re-render and the banner appears with the correct text.

What alternative solutions did you explore? (Optional)

• Show a loading/placeholder state in the banner — adds complexity without clear UX benefit; it's cleaner to simply not show the banner until the data is ready.
• Fix in the Banner component itself — making Banner hide when text is empty would change shared component behavior and could affect other callers.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[Valforte]

@MelvinBot implement this

[MelvinBot]

🤖 Draft PR created: #88605
Please mark it as "Ready for review" when it is ready for review.

[Valforte]

@MelvinBot why is the account manager info not loading? It should always be present as it's loaded into the account Onyx key during OpenApp. Hiding the banner is not the correct fix here.

[MelvinBot]

You're right — my previous analysis was wrong. The account manager info IS available directly on the account Onyx key, and the banner should use it instead of the fragile 3-step lookup chain.

Root cause: AccountManagerBanner resolves the account manager's identity via ACCOUNT_MANAGER_REPORT_ID → load report → getParticipantsAccountIDsForDisplay → personal details lookup (AccountManagerBanner.tsx:25-29). If the report hasn't loaded into Onyx yet, the chain breaks and the text is blank. Meanwhile, account.accountManagerAccountID is populated directly during OpenApp and is always available — HelpPage.tsx:35-38 already uses this correctly.

Fix: Replace the 3-step chain with a direct read of ONYXKEYS.ACCOUNT to get accountManagerAccountID (and accountManagerReportID for the "Chat now" navigation), then look up personal details with that ID — matching the HelpPage pattern.

I'll close the existing draft PR and update the implementation.

---

Next Steps: Reply with @MelvinBot implement this to create a corrected draft PR, or @MelvinBot <your feedback> to refine further.

[Valforte]

@MelvinBot implement this