[No QA] Docs updates for E/A#93580 Connect an HR integration help article

[MelvinBot]

Explanation of Change

Help site update prompted by Expensify/App#93580, which expanded the workspace HR page from 3 Merge-based providers (BambooHR, HiBob, Workday) to 24 enabled providers and added a Find integration search field.

Previously the only HR provider help articles were the per-provider guides for BambooHR, HiBob, and Workday. The 21 newly added providers (and the new search field) had no documentation.

This PR adds one new help article, Connect an HR integration to Expensify, that documents the shared connection flow used by all Merge-based HR providers, lists the currently supported providers, and covers the new Find integration search. It cross-links to the existing per-provider articles and to Gusto/TriNet (which use a separate setup flow).

New file:

• docs/articles/new-expensify/connections/Connect-an-HR-integration-to-Expensify.md

All UI labels (HR, More features, Find integration, Connect, Complete setup, Cannot connect to multiple HR platforms, provider display names) were taken from the app's source strings in src/languages/en.ts and src/CONST/MERGE_HR_PROVIDERS.ts.

Note: Live-UI verification of the HR page could not be completed in this run because the test environment's dev app was stuck on the boot splash screen (0 rendered DOM nodes despite all assets loading). The labels above were verified against the app source, which is the source of the rendered strings — please confirm they match the live UI.

Fixed Issues

$ https://github.com/Expensify/Expensify/issues/648089

Tests

// TODO: The human co-author must fill out the tests you ran before marking this PR as "ready for review"
// Please describe what tests you performed that validates your changed worked.

QA

// TODO: The human co-author must fill out the QA tests you ran before marking this PR as "ready for review".
// Please describe what QA needs to do to validate your changes and what areas do they need to test for regressions.

---

@jmusial, please review the files changed and confirm they reflect the current behavior. Then post a new comment saying @MelvinBot mark this PR as ready for review.

[OSBotify]

A preview of your ExpensifyHelp changes have been deployed to https://0d638bb6.helpdot.pages.dev ⚡️

Updated articles:

• articles/new-expensify/connections/Connect-an-HR-integration-to-Expensify

[roryabraham]

I notice that we currently have separate help site pages for Gusto, BambooHR, HiBob, and Workday. I don't know if it's practical or helpful to have a separate page for every integration Merge.dev supports (how much redundancy would there be? would separate pages boost SEO?), but this PR adds just one help site page for all the HR integrations.

@MelvinBot would having separate help site pages for each HR integration be beneficial for SEO?

[MelvinBot]

Short answer: Yes, per-provider pages can help SEO — but only for providers with genuinely unique content or real search demand. Spinning up ~24 near-identical pages would more likely hurt than help, so the one-hub approach in this PR is the right default, with a small number of dedicated pages layered on top.

On redundancy: it would be very high. Comparing the existing per-provider articles — Connect-BambooHR-to-Expensify.md, Connect-HiBob-to-Expensify.md, Connect-Workday-to-Expensify.md — they're all 145 lines with the same structure and mostly the same text; the provider name is essentially find-and-replaced into a shared Merge connection flow. That's the crux of the SEO tradeoff.

Why 24 pages would likely hurt SEO:

• Thin/duplicate content. Google explicitly discourages sets of pages that are substantially the same with only a name swapped (its guidance on doorway/thin pages). Duplicates tend to get deprioritized or dropped from the index, and can dilute authority across the set rather than concentrating it.
• Keyword cannibalization. Multiple pages competing for the same "connect an HR integration" intent split ranking signals instead of consolidating them onto one strong page.

Why per-provider pages do help — in the right cases:

• People genuinely search "<provider> Expensify integration", so a page targeting that exact query can win long-tail traffic — but only if it carries unique value (provider-specific auth steps, quirks, screenshots, troubleshooting). That's exactly why BambooHR/HiBob/Workday already justify their own pages: they're high-demand and BambooHR's article, for instance, has provider-relevant extras (approval-mode config, manual-sync limits).

Suggested approach (hybrid):

1. Keep this consolidated hub page — it can rank for generic "HR integration" queries, and listing all 24 provider names as text already gives you some keyword coverage for each on one authoritative page.
2. Keep dedicated pages only where there's real unique content or proven search demand (the current three, plus Gusto/TriNet which use a different flow).
3. Add a new per-provider page later on a case-by-case basis — when you have provider-specific content worth writing or data showing search volume for that provider — rather than generating all 21 up front.

If you want to validate demand before investing, pull search-volume/impression data (Google Search Console, or a keyword tool) for a few "<provider> Expensify" terms; that'll tell you which of the 21 are actually worth their own page.

---

view run