[Due for payment 2026-10-22] [WIP] Consolidate integration to one Connection screen

@Krishna2323

Problem

Today the integrations we have are split across HR, Accounting, Receipt Partners, and MCP, and every new vertical means another left-nav item. It's already crowding out our own features, and it doesn't scale well past 60+ integrations.

Solution

Consolidate all integrations to in one place. This means:

One unified page showing all your connections
Tabs to browse by popular, all, or by category
Search across all of them
Errors surfaced clearly at the top with a way to fix them

The Design

Empty state

Two connections set up

Accounting integration warning

When you already have a integration set up we should still warn people if they try to connect another. Today's warning is a bit too soft so let's tweak the wording slightly and change the button color:

First time users

Given this is a navigational change, we should onboard the user by telling them that their integrations has moved. This tooltip should only show once and be dismissable:

More features

Let's also update More features given we don't need toggles for Accounting, Receipt Partners, or HR.

Onboarding

No changes made here. It should remain like it does today

Try it out yourself

Prototype link

Specs

Tabs: Popular, All, Accounting, People, Travel & Delivery, Al & MCP
Popular listings: QBO, Xero, NetSuite, Uber for Business, Claude, ChatGPT, Gusto, BambooHR

Figma file

cc @Expensify/design @Expensify/product

Issue Owner

Current Issue Owner: @Krishna2323

Do we want to make this external, @Expensify/product ?

Beautiful, let's get this in motion. We might consider asking a C+ to do this or an agency?

I can help if needed

@JmillsExpensify

@JmillsExpensify or @trjExpensify , any preference on who works on this?

@twisterdotcom

Have we figured out how we're going to handle connecting to the same integration for HRIS and ATS, or do we not need to do that here atm? CC: @twisterdotcom

Can I get more details on the example. Initially I though it should be two separate listings if it's different Auth, but I'm not sure anymore since what we'd wanna do with Gmail is one listing but multiple accounts added.

So I'd love some details:

What's the service?
What does the integration do?
What data can be synced?
Is there any major API difference between them (syncing times, etc etc)

Can we do something where when you click on the + in the initial connection card, we show a dropdown/popover with those two items? Then if you do connect via one of those two, the connected card that floats to the top might say "ConnectionName (HRIS)"

Then the connection would still remain in the table below where you could then add the other type - "ConnectName (ATS)" would show as a different card at the top as well once you connected that?

@trjExpensify

Is this what you mean? I could see that.

Let's hear what @trjExpensify and @twisterdotcom says though cause I'm curious what is a smoother experience and what matches the users mental model more. Whether they think of it as two separate things or one thing.

Can we please not hold up this implementation on this detail? I agree we need to discuss it and align on it for implementation but let's not delay implementing accounting/MCP and the rest of the framework on this. I'll find someone.

It is confusing, because the customer will not see them as two separate things, but to us, they are architecturally different, so this flow is one we need to explain to them. The selector above is fine.

I am also fine starting with defaulting to HRIS for any which cross both and we can build the selector as a V2.

Awesome, yeah let's focus on addressing Tom's other detailed feedback in the PR first.

@Gonals

Triggered auto assignment to @Gonals, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

Deploy Blocker #104009 was identified to be related to the PR #102265 that attempted to fix this issue.

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

Deploy Blocker #104011 was identified to be related to the PR #102265 that attempted to fix this issue.