[Due for payment 2026-07-29] Members - Import failed is shown when people admin imports members via CSV file

[applause-bot]

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.4.26-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92875
Email or phone of affected tester (no customers): noijonjoijosdijosjdio@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Create a Control workspace.
• Invite a member as people admin.
• Perform the steps below as people admin:

1. Go to staging.new.expensify.com
2. Go to workspace settings > Members.
3. Click More > Download CSV.
4. Click More > Import spreadsheet.
5. Upload the downloaded CSV.
6. Click Import.

Expected Result:

Members will be imported without issue with CSV file.

Actual Result:

Import failed is shown when people admin imports members via CSV file.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7196927_1782938806354.9.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7196927

Issue Owner

Current Issue Owner: @ShridharGoel

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/d5d92ffacb5ccbba9fc278679b41dc693c3fc3cdd9eb2d9fdfcbabf1de8c205e

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #92875

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Issue Analysis

Root Cause (Medium confidence): The "Import failed" modal is shown whenever the backend returns a non‑success jsonCode for the ImportMembersSpreadsheet command — see Member.ts:1074. So the failure originates server‑side, in the backend handling for the newly‑added People Admin role (the backend dependency Expensify/Web-Expensify#53610 linked in #92875), not in the NewDot UI.

The most likely trigger is the repro's specific flow — re‑importing the full downloaded members CSV. That CSV contains every existing member, including Workspace Admins with role="admin". When a People Admin re‑imports it, the frontend keeps each existing member's current role (a People Admin can't manage the admin role, so the row isn't downgraded) and sends role="admin" rows to the backend. The backend appears to reject the request because a People Admin isn't allowed to assign/keep the admin role, failing the whole import.

This is not fixable in Expensify/App. The rejection happens in the backend ImportMembersSpreadsheet handler (Web-Expensify), so it needs an internal engineer with access to that repo. The backend should let a People Admin import members without failing on rows whose elevated role is unchanged (or scope the permission check to only the roles actually being changed).

⚠️ I could not pull staging logs from this environment to confirm the exact backend jsonCode/error, so the precise server-side mechanism (top-level permission gate vs. per-row role=admin validation) is unverified.

Investigation details

How the failure surfaces (App side):

• importMembers calls importPolicyMembers, which returns getImportFailedFinalModal() when response?.jsonCode !== CONST.JSON_CODE.SUCCESS — Member.ts:1069-1077. The "Import failed" copy is spreadsheet.importFailedTitle in en.ts.

Why admin rows get sent for a People Admin re-import:

• People Admin has MEMBERS: WRITE but not ASSIGN_ELEVATED_ROLES — PolicyUtils.ts:165-170.
• canMemberAssignElevatedRole is true for a People Admin on Control (they can assign up to Auditor) — PolicyUtils.ts:230-232 — so the imported-role logic runs.
• For each existing member the row starts as its current role; the imported role only overrides it when canMemberManageMemberWithRole and canMemberAssignRole pass — ImportedMembersPage.tsx:150-160. For a Workspace Admin row, canMemberAssignRole(policy, peopleAdmin, "admin") is false (PolicyUtils.ts:208-227), so the row keeps role="admin" and is submitted to the backend as-is.

Alternative explanations considered:

• Backend blocks the People Admin role entirely from ImportMembersSpreadsheet — also plausible and also a Web-Expensify fix. Logs would disambiguate this from the role=admin hypothesis.
• Pure frontend bug (e.g. empty role sent) — ruled out: for a full CSV re-import all rows resolve to a valid existing role, and canAssignElevatedRoles being true skips the role = USER fallback.

To verify in logs (couldn't run here): search {type=web} "ImportMembersSpreadsheet" for tester noijonjoijosdijosjdio@gmail.com on 2026-07-01 and read the returned jsonCode/error.

Related (not a duplicate): feature-tracking issue #90502.

---

Next Steps for Contributor+ team: This is a backend issue in Web-Expensify (People Admin support for ImportMembersSpreadsheet, Expensify/Web-Expensify#53610) — an internal engineer with access to that repo should take it. As a temporary deploy-blocker mitigation, consider reverting #92875 if the backend fix can't land quickly.
Reply with @MelvinBot <your feedback> to refine this analysis.