Allow full-access copilots to add new company card feeds

[MelvinBot]

Explanation of Change

PR #52103 restricted Copilots (delegates) from adding new company card feeds. The add-new-feed flow gated on isActingAsDelegate with the DENIED_ACCESS_VARIANTS.DELEGATE wrapper variant, whose predicate is just isDelegate — so it blocks every copilot, full-access included.

That's too broad: a full-access copilot can already add a card feed in Expensify Classic (a Domain Admin action), and NewDot already allows full Copilot access for Expensify Card issuing (#81817). This PR mirrors #81817 exactly — it swaps the gate from "any delegate" to "limited/submitter delegates only":

• DynamicAddNewCardPage.tsx — source isDelegateAccessRestricted from useDelegateNoAccessState() (as DynamicIssueNewCardPage does), gate on it instead of isActingAsDelegate, and change the DelegateNoAccessWrapper variant from DELEGATE → SUBMITTER.
• WorkspaceCompanyCardPageEmptyState.tsx — gate the empty-state "Add cards" CTA on isDelegateAccessRestricted instead of isActingAsDelegate.

isDelegateAccessRestricted is isActingAsDelegate && isDelegateOnlySubmitter(account), so after this change a full-access copilot passes into the add-new-feed flow (BYOC and CSV), while limited/submitter copilots still hit the no-access view. Assigning already-issued cards and issuing Expensify Cards were already allowed and are unchanged.

⚠️ This only lifts the client-side gate. Server-side authorization for the add-feed commands (AddNewCompanyCardsFeed / OpenPolicyAddCardFeedPage and the CSV import path) lives in Web-Expensify/Auth and is not verifiable from this repo — an internal engineer should confirm the backend permits a full-access copilot's add-feed call.

Fixed Issues

$ #98328
PROPOSAL: #98328 (comment)

Tests

// TODO: The human co-author must fill out the tests before marking this PR "ready for review". Suggested coverage: (1) as a full-access copilot of an account that admins a workspace with Company cards enabled, open the workspace Company cards page, click "Add cards", and verify the add-new-feed flow opens (no "no access" modal); (2) as a limited/submitter copilot, verify "Add cards" still shows the no-access modal / view; (3) as the account owner (not a copilot), verify no regression to the add-new-feed flow.

• Verify that no errors appear in the JS console

Offline tests

QA Steps

// TODO: The human co-author must fill out the QA steps before marking this PR "ready for review".

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

[MelvinBot]

I created this PR from an upstream branch since I don't have push access to your fork.

To take ownership of this branch and be able to push updates, run:

git remote add upstream https://github.com/Expensify/App.git
git fetch upstream claude-copilotAddCardFeed
git checkout -b claude-copilotAddCardFeed upstream/claude-copilotAddCardFeed
git push -u origin claude-copilotAddCardFeed

Then you can close this PR and open a new one from your fork.

[MelvinBot]

🤖 I looked into the failing checks — there's no code fix to push. Both failures are process/checklist checks, not code issues:

Check	Why it's failing
checklist (PR Author Checklist)	"You completed 0 out of 38 checklist items." These boxes attest to human testing (ran on all platforms, offline behavior, screenshots, etc.), and the PR body still has // TODO: The human co-author must fill out... placeholders in the Tests and QA Steps sections.
Check independent approval	Fails on "Verify peer review" — it just needs a reviewer to approve the PR.

Every actual code check is green: test (job 2–8), typecheck, ESLint check, Oxfmt check, Bun tests, Storybook tests, React Compiler Compliance, spellcheck, and the Dev builds all pass. The remaining perf/build/test (job 1) items were still pending, not failing.

To clear the two failures:

1. Fill out the Tests / QA Steps and check off the PR Author Checklist items (this is human-only work — I can't legitimately check boxes attesting to manual cross-platform testing).
2. Get a peer review approval.

Since these aren't code defects, I didn't push any commit. Let me know if you'd like me to dig into anything else.

[MelvinBot]

🤖 Re-checked — one real check is now failing (test (job 1)), but it's unrelated to this PR, so I didn't push a fix.

Failing test: tests/unit/SignInBackButtonTest.tsx → sign-in Android hardware back handling › SignInModal › registers no back listener… with TypeError: _Navigation.default.dismissModal is not a function.

Why it's unrelated: This PR changes only two company-card files (WorkspaceCompanyCardPageEmptyState.tsx and DynamicAddNewCardPage.tsx). It touches nothing in sign-in or navigation, so it can't have caused this. The test's inline Navigation mock defines only goBack and omits dismissModal (SignInBackButtonTest.tsx:11-24), while SignInModal calls Navigation.dismissModal() (SignInModal.tsx:60). This is a pre-existing gap on main (the test file was last modified by Expensify/App#97816), not something this branch introduced.

Suggested fix (in that unrelated file, for its owner): add dismissModal: jest.fn() to the mocked default object in SignInBackButtonTest.tsx. I'm not pushing it here since it's outside this PR's scope — merging main once that's fixed on main should clear it.

The other two failures are still the process checks — checklist (PR Author Checklist, human-only) and Check independent approval (needs a reviewer approval). Neither is a code defect.

Full check status

• ❌ test (job 1) — unrelated SignInBackButtonTest.tsx failure (above)
• ❌ checklist — 0/38 human checklist items; Tests/QA sections still have the human-co-author TODO placeholders
• ❌ Check independent approval — needs a reviewer approval
• ✅ test (job 2–8), typecheck, ESLint check, Oxfmt check, Bun tests, Storybook tests, React Compiler Compliance, spellcheck, Dev builds
• ⏳ build (developmentDebug / Debug), baseline-perf-tests — still pending, not failing

[shubham1206agra]

@MelvinBot Merge main please

[MelvinBot]

🤖 Merged main into claude-copilotAddCardFeed and pushed.

The merge was clean — no conflicts. The PR's net diff against main is unchanged (still just the two intended files):

• src/pages/workspace/companyCards/addNew/DynamicAddNewCardPage.tsx
• src/pages/workspace/companyCards/WorkspaceCompanyCardPageEmptyState.tsx

Merge commit: 5ab35357ef9.

[codecov]

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
...ompanyCards/WorkspaceCompanyCardPageEmptyState.tsx	0.00% <0.00%> (ø)
...pace/companyCards/addNew/DynamicAddNewCardPage.tsx	0.00% <0.00%> (ø)
... and 8 files with indirect coverage changes

[shubham1206agra]

@MelvinBot What is the reason for changing this line?

[MelvinBot]

Line 95 swaps the DelegateNoAccessWrapper variant from DENIED_ACCESS_VARIANTS.DELEGATE to DENIED_ACCESS_VARIANTS.SUBMITTER so the inner guard matches the new outer gate and only blocks limited/submitter copilots — not full-access ones.

The two variants apply different predicates in DelegateNoAccessWrapper.tsx:22-26:

• DELEGATE → isDelegate(account) — true for every delegate (full-access included)
• SUBMITTER → isSubmitter(account) — true only for delegate-only submitters (limited access)

Since the outer branch condition was changed to isDelegateAccessRestricted (acting as delegate and submitter-only), the wrapper's own predicate has to change too, otherwise the two layers would disagree about who is blocked. This makes the whole page consistently allow full-access copilots into the add-feed flow while still blocking limited/submitter copilots — mirroring the Expensify Card issue-new page (DynamicIssueNewCardPage.tsx:149) from #81817, which already uses the SUBMITTER variant.

[MelvinBot]

Analyzed the failing checks — no code fix is needed. Every check that validates the code passes (Bun tests, test jobs, typecheck, ESLint, Oxfmt, Storybook, builds, and both branch/baseline perf tests).

The two remaining ❌ are process gates, not code failures, so there's nothing to push:

• Check independent approval — fails because the PR doesn't yet have an approval from an independent reviewer.
• PR Reviewer Checklist / checklist — fails because a reviewer hasn't completed the reviewer checklist.

Both clear on their own once this PR is marked "Ready for review" and a reviewer approves + completes their checklist. As a reminder, the human co-author still needs to fill in the Tests and QA Steps sections (currently // TODO) before this can move forward.

[MelvinBot]

No fix to push — the code is green. All checks that validate code pass (Bun tests, test jobs, typecheck, ESLint, Oxfmt, Storybook, builds, and both perf tests).

The only two ❌ are non-code process gates that clear through review, not by pushing commits:

• Check independent approval — waiting on an approval from an independent reviewer.
• PR Reviewer Checklist / checklist — waiting on a reviewer to complete their checklist.

To move this forward: fill in the Tests and QA Steps sections (still // TODO), mark the PR "Ready for review," and have a reviewer approve and complete their checklist.

[shubham1206agra]

@MelvinBot Merge main please

[MelvinBot]

🤖 Merged main into claude-copilotAddCardFeed and pushed — no conflicts. The merge commit is 9104728.

[MelvinBot]

There's no failing check that a code change can fix here — nothing to push.

The only failing check is Check independent approval, which fails at its Verify peer review step. That's a process gate, not a code problem: it stays red until an independent human reviewer approves the PR. Pushing code won't clear it.

Every actual code/build/test check is green:

• ESLint, typecheck, and all 8 test jobs — pass
• All build jobs, Storybook tests, Bun tests, Oxfmt, React Compiler Compliance, unused-styles/knip checks — pass
• branch-perf-tests — pass

The one remaining pending check, baseline-perf-tests, runs against the main baseline and is independent of this PR's changes — just let it finish.

Next step: get an independent reviewer to approve the PR to satisfy the Check independent approval gate.

[shubham1206agra]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified proper code patterns were followed (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately and each prop has a /** comment above it */
  • The file is named correctly
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
  • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
  • All JSX used for rendering exists in the render method
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Screen.Recording.2026-08-19.at.5.58.57.PM.mov

[shubham1206agra]

@MelvinBot Ready this PR for review

[melvin-bot]

@shubham1206agra Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[MelvinBot]

🤖 Marked this PR as ready for review.

[melvin-bot]

We did not find an internal engineer to review this PR, trying to assign a random engineer to #98328 as well as to this PR... Please reach out for help on Slack if no one gets assigned!

[mollfpr]

@shubham1206agra, the PR author checklists and test steps are not filled, is it expected to be left empty?

[shubham1206agra]

@mollfpr Yes

[mollfpr]

All yours @joekaufmanexpensify cc @trjExpensify

[trjExpensify]

@shubham1206agra in your video evidence, please go through the flow and actually add a new card feed as a copilot.

[shubham1206agra]

@trjExpensify Here you go

Screen.Recording.2026-08-20.at.5.46.00.PM.mov

[trjExpensify]

@trjExpensify Here you go

Screen.Recording.2026-08-20.at.5.46.00.PM.mov

Did you do a connected card feed as well like "Mock bank"?

[shubham1206agra]

@trjExpensify Here you go
Screen.Recording.2026-08-20.at.5.46.00.PM.mov

Did you do a connected card feed as well like "Mock bank"?

@trjExpensify I think this is an Internal QA task as I don't I can add any feed apart from CSV.

[trjExpensify]

@trjExpensify Here you go
Screen.Recording.2026-08-20.at.5.46.00.PM.mov

Did you do a connected card feed as well like "Mock bank"?

@trjExpensify I think this is an Internal QA task as I don't I can add any feed apart from CSV.

Yeah, you can. Click Direct feed and then choose the Mock bank option.

[shubham1206agra]

Screen.Recording.2026-08-24.at.8.19.39.PM.mov

@trjExpensify Here you go

[trjExpensify]

Thanks! 👍

[trjExpensify]

@mollfpr feel free to merge.

[shubham1206agra]

@mollfpr Bump here

[github-actions]

🚧 mollfpr has triggered a test Expensify/App build. You can view the workflow run here.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #98600.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-8cddbe6-3cda03c-b235c5d2ef1f3dda36bcd2802eeaa8e9e077a82a/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-8cddbe6-3cda03c-90a9039cda3a356fc173d6548d5a7824d0e0a58f/index.html

Web 🕸️
https://98600.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[OSBotify]

🚀 Deployed to staging by https://github.com/mollfpr in version: 9.4.66-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

[MelvinBot]

Yes, help site changes are required. Draft PR: #100095

Why: this PR lets a Full Access copilot open the add-new-feed flow, but the feed-setup articles only said "Any Workspace Admin can…", so they read as admin-only and never mentioned copilots at all.

What changed in the docs PR

Article	Change
Set up a Direct Company Card Feed Connection	Copilot access rule added to the "Who can…" section, plus keywords and internalScope audience
Set up a Commercial Card Feed Connection	Same
Import Company Card Transactions From a Spreadsheet	Same, and corrected Company Cards → Company cards and Add card → Add cards to match the product
Act as a Copilot	New FAQ: "Can I add a company card feed as a Copilot?"

Two things to check when you review:

1. The live-UI check didn't run. The handed-off browser session never got past the splash screen, so I couldn't sign in. Labels came from src/languages/en.ts on main instead — workspace.companyCards.addCards is Add cards, workspace.moreFeatures.companyCards.title is Company cards. Access levels render as Full / Limited in delegate.role, but the articles use the existing help site wording Full Access / Limited Access for consistency with the copilot articles.
2. Backend authorization. As this PR's description notes, only the client-side gate was lifted. If the server still rejects a full-access copilot's add-feed call, the new docs text overstates what works.

Articles I checked and left alone

• Assign-Company-Cards.md — already says "Workspace Admins, Card Admins, and their Copilots", and assigning was never gated on delegate status (no isDelegateAccessRestricted check in the assign flow). Still accurate.
• Manage-Copilot-Access.md — describes granting access, not what a copilot can do on the company cards page. Out of scope.
• Fix-a-Broken-Company-Card-Feed-Connection.md, Configure-Company-Card-Settings.md, Share-a-Company-Card-Connection-Across-Workspaces.md — no copilot or add-feed permission claims.
• Expensify Classic copilot articles — unaffected; this change is New Expensify only.

@shubham1206agra, please review the linked help site PR and confirm it reflects the current behavior. Then mark the linked help site PR Ready for review

---

view run

[OSBotify]

🚀 Deployed to staging by https://github.com/mollfpr in version: 9.4.68-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	cancelled 🔪

[OSBotify]

🚀 Deployed to production by https://github.com/francoisl in version: 9.4.68-1 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

• Android