[$250] Invite Message Formatting Not Synced Between New and Classic Platforms

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.49-2
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @abbagail
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

On Classic:

1. Go to Settings > Workspace > [Workspace Name] > Members
2. Click Invite
3. Observe that the personal message retains formatting from a previous invite

On New:

1. Go to Workspace > [Workspace Name] > Invite
2. Enter a new email address
3. Select user role and proceed
4. Navigate to invite message settings
5. Observe a generic invite message (previous message not retained)
6. Edit the message (add links/formatting)
7. Send invite

Switch back to Classic:

1. Go to Settings > Workspace > [Workspace Name] > Members
2. Click Invite
3. Observe that the personal message now displays raw HTML formatting
4. Send invite → formatting is not rendered correctly

Expected Result:

Invite messages should sync between New and Classic platforms
Formatting (links, styling, etc.) should render consistently across both platforms
Messages saved in one platform should appear correctly formatted in the other

Actual Result:

New platform does not load previously saved invite messages
Messages edited in New appear as raw HTML in Classic
Invite emails sent from Classic do not render formatting properly

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Recording.2596.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mollfpr

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022037272107131411229
• Upwork Job ID: 2037272107131411229
• Last Price Increase: 2026-04-02

[MelvinBot]

Proposal

What is the root cause of that problem?

There are two distinct root causes driving this issue:

1. Format mismatch: App sends HTML, Classic expects plain text

When a user sends a workspace invite from New Expensify, the invite message goes through this conversion chain:

• User types in a markdown-enabled input (WorkspaceInviteMessageComponent.tsx:267)
• A markdown heading is prepended: # {name} invited you to {workspace}\n\n{message} (line 135)
• Parser.replace(welcomeNote, {shouldEscapeText: false}) at Member.ts:998-1000 converts the markdown to HTML (e.g., <h1>John invited you to My Workspace</h1>)
• This HTML string is sent to the backend as the welcomeNote parameter in AddMembersToWorkspace

Classic reads this stored value and renders it as plain text, so raw HTML tags like <h1>, <br />, <a href="..."> appear in the Classic invite form instead of rendered formatting.

2. App never loads server-stored invite messages

The App's getDefaultWelcomeNote() at WorkspaceInviteMessageComponent.tsx:101-103 only checks:

1. Local form draft data
2. Local Onyx WORKSPACE_INVITE_MESSAGE_DRAFT
3. Hardcoded default: "Please use Expensify to submit your receipts for reimbursement, thanks!"

It never reads a server-stored invite message from the policy. The Policy Onyx type has no personalMessage or inviteMessage field. So messages previously saved in Classic are invisible to New Expensify.

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

Fix 1: Stop converting the invite message to HTML before sending

In App/src/libs/actions/Policy/Member.ts:998-1000, the welcomeNote is converted from markdown to HTML via Parser.replace() before being sent to the backend. Since Classic expects plain text (not HTML), the App should either:

• Send the raw markdown/plain text directly (remove the Parser.replace() call), or
• Check what format the backend expects and match it (the workspace description page at WorkspaceOverviewDescriptionPage.tsx:31 handles a similar round-trip correctly using Parser.htmlToMarkdown when loading and Parser.replace when saving — but the invite message has no corresponding load-from-server step)

Fix 2: Load the server-stored invite message from the policy

The OpenWorkspaceInvitePage API response likely includes the previously-saved invite message (as a policy field like personalMessage). The App should:

• Add the relevant field to the Policy Onyx type
• Read it in WorkspaceInviteMessageComponent.tsx as the default value (with Parser.htmlToMarkdown conversion if it's stored as HTML)
• Fall back to the local draft and then the hardcoded default only if the server field is empty

What alternative solutions did you explore? (Optional)

An alternative would be to have the backend handle the format conversion (store as HTML internally, serve as plain text to Classic and HTML to New). However, this would require backend changes and doesn't address the fact that the App ignores the server-stored message entirely. The client-side fix is more straightforward and addresses both symptoms.

---

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.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @linhvovan29546 (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022037272107131411229

[twilight2294]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Invite messages edited in New Expensify appear as raw HTML in Classic, and previously saved invite messages from Classic are not loaded when opening the invite page in New Expensify. The two platforms are completely out of sync on invite message formatting and persistence.

What is the root cause of that problem?

There are two root causes.

1. NewDot converts markdown to HTML before sending to the API. In addMembersToWorkspace() in Member, the invite message is run through Parser.replace() which converts markdown to HTML (**bold** → <strong>bold</strong>). Classic's invite form treats the stored value as plain text, so users see raw <h1>, <br />, <a href="..."> tags instead of rendered formatting.

2. NewDot never reads the server-stored invite message. In getDefaultWelcomeNote() in WorkspaceInviteMessageComponent, the fallback chain is: form draft → local Onyx draft → hardcoded default. The welcomeNote field returned by the API on the policy object is completely ignored because (a) the Policy type in Policy doesn't define a welcomeNote field, and (b) the component never reads from it.

Additionally, the subject line prefix (# Name invited you to Workspace) is concatenated into the welcomeNote before sending at line 135, meaning it gets stored on the policy. If the stored note is later loaded back, the subject would be duplicated on the next invite — an edge case the existing proposal does not address.

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

1. Remove Parser.replace() in Member:

// Before:
welcomeNote: Parser.replace(welcomeNote, {
    shouldEscapeText: false,
}),

// After — send raw text directly:
welcomeNote,

2. Add welcomeNote to the Policy type in Policy:

/** Welcome note sent to invited members, keyed by role */
welcomeNote?: Record<string, string>;

3. Read the stored note in WorkspaceInviteMessageComponent, stripping any previously-stored subject prefix and converting legacy HTML:

const getDefaultWelcomeNote = useCallback(() => {
    if (formData?.[INPUT_IDS.WELCOME_MESSAGE]) {
        return formData[INPUT_IDS.WELCOME_MESSAGE];
    }
    if (workspaceInviteMessageDraft) {
        return workspaceInviteMessageDraft;
    }

    // Read from server-synced policy welcomeNote
    const policyNote = policy?.welcomeNote;
    if (policyNote) {
        const role = workspaceInviteRoleDraft ?? CONST.POLICY.ROLE.USER;
        const noteForRole = policyNote[role] ?? policyNote[CONST.POLICY.ROLE.USER] ?? '';
        if (noteForRole) {
            // Convert any legacy HTML back to markdown, then strip the
            // "# Name invited you to Workspace\n\n" subject prefix so it
            // isn't duplicated when the component re-prepends it on send
            let cleaned = Parser.htmlToMarkdown(noteForRole);
            cleaned = cleaned.replace(/^#\s.+?\n\n/, '');
            return cleaned;
        }
    }

    return translate('workspace.common.welcomeNote');
}, [workspaceInviteMessageDraft, translate, formData, policy?.welcomeNote, workspaceInviteRoleDraft]);

What alternative solutions did you explore? (Optional)

The existing MelvinBot proposal identifies the same two root causes and proposes the same high-level fixes. My proposal improves on it in two ways:

1. Subject prefix duplication — Because the full message including # Name invited you to Workspace\n\n is stored on the policy, loading it back and re-prepending the subject on the next send would duplicate it. The regex strip in step 3 above handles this. The existing proposal does not address this edge case.
2. Role-based lookup — The welcomeNote is stored as a record keyed by role (e.g., {user: "...", admin: "..."}). My proposal provides concrete code for resolving the correct note based on workspaceInviteRoleDraft, falling back to the USER role.

[trasnake87]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Invite messages edited in New Expensify appear as raw HTML (<h1>, <br />, etc.) when viewed in Classic, and previously saved invite messages from Classic are not loaded in New Expensify.

What is the root cause of that problem?

The root cause is in sendInvitation() at WorkspaceInviteMessageComponent.tsx#L135, which silently concatenates a markdown heading (# Name invited you to Workspace) into the welcomeNote body before passing it to the API. This heading is constructed at line 96–97 but is never shown to the user in the UI — it's invisible metadata that gets permanently baked into the stored message. The combined markdown string then flows to addMembersToWorkspace() at Member.ts#L998, where Parser.replace() converts the entire thing (heading + body) into HTML like <h1>John invited you to My Workspace</h1><br/>.... Classic reads this stored value as plain text and renders the raw tags.

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

Stop embedding the subject heading into the welcomeNote payload and stop converting it to HTML. The backend composes its own invitation header when sending the email — the client should only send the user's actual message body.

In src/pages/workspace/members/WorkspaceInviteMessageComponent.tsx, change line 135 to pass only welcomeNote:

- addMembersToWorkspace(invitedEmailsToAccountIDsDraft ?? {}, `${welcomeNoteSubject}\n\n${welcomeNote}`, policy, policyMemberAccountIDs, workspaceInviteRoleDraft, formatPhoneNumber);
+ addMembersToWorkspace(invitedEmailsToAccountIDsDraft ?? {}, welcomeNote ?? '', policy, policyMemberAccountIDs, workspaceInviteRoleDraft, formatPhoneNumber);

In src/libs/actions/Policy/Member.ts, remove the Parser.replace() call at line 998 and send the welcome note as-is:

- welcomeNote: Parser.replace(welcomeNote, {
-     shouldEscapeText: false,
- }),
+ welcomeNote,

This is safe because the backend already handles text formatting for invite emails — Parser.replace() was producing HTML that no consumer (Classic or email) expected in that field.

What alternative solutions did you explore? (Optional)

Considered converting HTML back to plain text with Parser.htmlToText() before sending, but that adds unnecessary complexity when the simpler fix is to stop generating HTML in the first place.

[ReaperOAK]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[trasnake87]

Contributor details
Your Expensify account email: trasnake87@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010f770315ab181656

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!