[No QA] Add Coming from Expensify Classic help site article

[MelvinBot]

Explanation of Change

Adds a new help site article "Coming from Expensify Classic" under docs/articles/new-expensify/getting-started/. This migration guide maps familiar Expensify Classic concepts and features to their New Expensify equivalents, helping transitioning users find what they need without contacting support.

The article follows HELPSITE_NAMING_CONVENTIONS.md, HELP_AUTHORING_GUIDELINES.md, and TEMPLATE.md guidelines, including task-based headings, exact UI terminology, YAML metadata, and relative cross-links.

Fixed Issues

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

PROPOSAL:

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.

• Verify that no errors appear in the JS console

Offline tests

N/A — this is a documentation-only change.

QA Steps

// 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.

• 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 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 shown in the product is localized by adding it to src/languages/* files and using the translation method
    • If any non-english text was added/modified, I used JaimeGPT to get English > Spanish translation. I then posted it in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • 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)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• 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)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• 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 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.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• 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

N/A — documentation only

Android: mWeb Chrome

N/A — documentation only

iOS: Native

N/A — documentation only

iOS: mWeb Safari

N/A — documentation only

MacOS: Chrome / Safari

N/A — documentation only

[MelvinBot]

Fixed the failing spellcheck: added reimagines to the cspell dictionary.

[MelvinBot]

The only failing check is the PR Author Checklist, which requires manual completion by the PR author — it's not a code issue. All code checks (ESLint, Prettier, spellcheck, etc.) are passing. The build and perf-tests checks are still pending/in-progress.

To resolve the checklist failure, complete the author checklist items in the PR description.

[MelvinBot]

The perf-tests failure is unrelated to this PR — no fix needed here.

Failing check: Reassure Performance Tests — render count for [ReportActionsList] should render ReportActionsList with 500 reportActions stored exceeded the allowed deviation of 0 (current difference: 2).

Why it's unrelated: This PR only modifies cspell.json and a help-site markdown article. The render count regression in ReportActionsList is a pre-existing issue on main, not caused by documentation changes.

The only other failing check is checklist (PR Author Checklist), which requires manual completion.

To proceed: Re-run the perf-tests workflow (it may be flaky), or wait for the underlying regression to be fixed on main.

[MelvinBot]

Fixed the spellcheck failure: corrected typo configire → configure in the migration guide YAML metadata.

The build failure (Repository access blocked) is an infrastructure issue unrelated to this PR — it should resolve on re-run.

[MelvinBot]

The failing build check is unrelated to this PR's changes.

Analysis: The build failed during "Set up job" with Repository access blocked — a GitHub Actions infrastructure/permissions error before any code was compiled or tested. This is not caused by the documentation changes in this PR.

Evidence: The build run never reached the code checkout step. The error occurs at the runner level, not in any file this PR touches.

Recommendation: Re-run the failed build workflow. If it persists, it may need attention from someone with repo admin access.

[MelvinBot]

The failing build check is unrelated to this PR's changes.

Analysis: The build failed with Repository access blocked during the "Set up job" phase — before any code was even checked out. This is a GitHub Actions infrastructure/permissions issue, not a code problem.

Evidence: This PR only changes documentation files (cspell.json, two markdown articles under docs/). The failure occurred at the CI runner level, not during compilation or tests. Re-running the workflow should resolve it.

[MelvinBot]

The failing build check is unrelated to this PR's changes — it failed during job setup with Repository access blocked, which is a GitHub Actions infrastructure/permissions issue.

Evidence: The failure occurs before any code is checked out or built. The PR only adds a markdown documentation file, and all code-related checks (ESLint, Prettier, spellcheck, verify) passed.

Re-running the failed workflow should resolve it.

[melvin-bot]

Concierge reviewer checklist:

• I have verified the accuracy of the article
  • The article is within a hub that makes sense, and the navigation is correct
  • All processes, screenshots, and examples align with current product behavior.
  • All links within the doc have been verified for correct destination and functionality.
• I have verified the readability of the article
  • The article's language is clear, concise, and free of jargon.
  • The grammar, spelling, and punctuation are correct.
  • The article contains at least one image, or that an image is not necessary
• I have verified the formatting of the article
  • The article has consistent formatting (headings, bullet points, etc.) with other HelpDot articles and that aligns with the HelpDot formatting standards.
  • The article has proper text spacing and breaks for readability.
• I have verified the article has the appropriate tone and style
  • The article's tone is professional, friendly, and suitable for the target audience.
  • The article's tone, terminology, and voice are consistent throughout.
• I have verified the overall quality of the article
  • The article is not missing any information, nor does it contain redundant information.
  • The article fully addresses user needs.
• I have verified that all requested improvements have been addressed

For more detailed instructions on completing this checklist, see How do I review a HelpDot PR as a Concierge Team member?

cc @brianlee-expensify

[melvin-bot]

@parasharrajat @brianlee-expensify One of you needs to 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]

The failing checks are unrelated to this documentation-only PR.

1. build — Repository access blocked during CI runner setup. This is an infrastructure/permissions issue, not caused by any code change.
2. perf-tests — Render count difference exceeded the allowed deviation of 0. Current difference: 2 in ReportActionsList. This PR only adds markdown docs and a cspell dictionary word — no React components were modified.

Recommendation: Re-run the failing checks. If build continues to fail, it may need CI infrastructure investigation. The perf-tests failure is a flaky/pre-existing render count issue unrelated to this PR.

[github-actions]

Terminology violation: The word "policy" should be "Workspace" to match current Expensify UI terminology (per HELPSITE_NAMING_CONVENTIONS.md). Suggested fix:

Suggested change

	keywords: [Expensify Classic admin, New Expensify Workspace Admin, company cards, approval workflows, Workspace rules, migration guide]
	description: Learn how familiar Workspace management, approval, reimbursement, company card, and Workspace rule workflows work in New Expensify.

[brianlee-expensify]

@stephanieelliott thoughts on the suggested change?

[github-actions]

HelpDot Documentation Review

Overall Assessment

This PR adds two new migration guides under docs/articles/new-expensify/getting-started/ -- one for Submitters and Approvers and one for Workspace Admins transitioning from Expensify Classic to New Expensify. The articles are well-structured, clearly written, and provide practical orientation through comparison tables, task mappings, and FAQ sections. A minor cspell.json update is also included.

Scores Summary

• Readability: 9/10 - The comparison tables and task-mapping tables are scannable and well-organized. Prose is concise and benefit-focused. The only minor concern is that table cells with long content (e.g., the "What changed" column) may be harder to scan on narrow viewports.
• AI Readiness: 8/10 - Both articles include complete YAML metadata with internalScope, task-based headings starting with "How" or question words, and feature-specific language. Minor deduction: these articles intentionally cover multiple workflows (migration guides), which works against the "one primary workflow per article" rule in Section 1 of the authoring guidelines. This is a reasonable exception for a "getting started" guide, but worth acknowledging.
• Style Compliance: 8/10 - UI terminology is correctly bolded, the three dots menu reference is properly formatted, and cross-links use relative paths with descriptive anchor text. Two issues noted below.

Key Findings

Positive aspects:

• Both articles follow the heading hierarchy strictly (one H1 title, H2 sections, H1 FAQ) with no forbidden heading types
• YAML frontmatter is complete and well-crafted, with meaningful internalScope declarations that clearly define audience and exclusions
• Cross-links use descriptive anchor text (e.g., "Learn what actions Concierge can take on expenses") and relative paths throughout
• The three dots menu in the Submitters article correctly uses the three dots **(⋮)** format
• Tables provide a practical, scannable way to map Classic concepts to New Expensify equivalents
• FAQ questions use proper question-word headings

Issues to address:

1. Lowercase "workspace" in FAQ heading (Admins article, line 79): The heading reads "Is there a guide for New Expensify that I can share with workspace members?" -- per HELPSITE_NAMING_CONVENTIONS.md, "Workspace" is a proper UI term and should be capitalized as Workspace members.

2. External URL in Admins article (line 60): The link to https://use.expensify.com/blog/category/Product+Updates is a full external URL. Per HELP_AUTHORING_GUIDELINES.md Section 7 (Link Formatting): "Use relative links only. Do not use full URLs." If this resource cannot be linked relatively, consider whether it is necessary or if it should be noted differently.

3. Multi-workflow coverage (both articles): The authoring guidelines state "Solve one primary workflow only" and "If multiple workflows are detected, split into multiple articles." These migration guides inherently cover multiple workflows. Given their purpose as orientation content in the "getting-started" hub, this is a reasonable exception, but worth a deliberate acknowledgment from the author.

Recommendations

1. Required: Capitalize "Workspace" in the FAQ heading on line 79 of the Admins article to match UI terminology conventions.
2. Required: Address the full external URL on line 60 of the Admins article -- either convert to a relative link if possible, or justify the exception.
3. Optional: Consider adding a brief note at the top of each article (or in a comment) acknowledging the intentional multi-workflow scope as a migration guide exception to the single-workflow rule, to prevent future reviewers from flagging it.

Files Reviewed

• cspell.json -- Added "reimagines" to dictionary. No issues.
• docs/articles/new-expensify/getting-started/Coming-from-Expensify-Classic-for-Submitters-and-Approvers.md -- New migration guide. Well-structured, minor items only.
• docs/articles/new-expensify/getting-started/Coming-from-Expensify-Classic-for-Workspace-Admins.md -- New migration guide. Two style issues noted above (lowercase "workspace", external URL).

[OSBotify]

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

Updated articles:

• articles/new-expensify/getting-started/Coming-from-Expensify-Classic-for-Submitters-and-Approvers
• articles/new-expensify/getting-started/Coming-from-Expensify-Classic-for-Workspace-Admins

[github-actions]

HelpDot Documentation Review

Overall Assessment

This PR introduces two well-crafted migration guides for users transitioning from Expensify Classic to New Expensify — one for Submitters/Approvers and one for Workspace Admins. Both articles are clearly written, use effective comparison tables, and provide strong cross-linking to deeper feature articles. The articles follow governance standards closely with only a few items to address.

Scores Summary

• Readability: 9/10 - Excellent use of comparison tables to map Classic workflows to New Expensify equivalents. Prose is clear, concise, and scannable. The "I want to..." table format is particularly effective for task-oriented readers.
• AI Readiness: 8/10 - YAML metadata is complete and well-formed with proper internalScope declarations. All headings use # and ## only, and every ## heading starts with an action verb or question word. Both articles include at least one "How to..." heading. Minor deduction: both articles intentionally cover multiple workflows (migration guides by nature), which diverges from the "one primary workflow per article" rule in Section 1 of HELP_AUTHORING_GUIDELINES.md, though this is a reasonable exception for the article type.
• Style Compliance: 8/10 - Button and tab names are consistently bolded. The three dots menu reference follows the exact required format. UI terminology is precise throughout. A few items need attention (detailed below).

Key Findings

• The comparison tables are an effective documentation pattern for migration content, making it easy for users to find where familiar workflows now live.
• Cross-links consistently use descriptive anchor text ("Learn how to..." format) and relative paths, fully compliant with cross-linking standards.
• FAQ sections are well-structured with question-word headings and direct answers.
• Both articles share two identical FAQ answers ("What new features can I use in New Expensify?" and "How do I know what to do next in New Expensify?"). This is not a governance violation, but consider whether the duplication could cause maintenance drift over time. If these answers need updating, both files must be changed.
• In the Workspace Admins article, the FAQ question "Is there a guide for New Expensify that I can share with workspace members?" uses lowercase "workspace" — this should be capitalized to Workspace to match UI terminology and naming conventions.
• Both articles use emoji symbols in FAQ answers (the green circle and red circle). While not explicitly prohibited, these may not render consistently across all help site platforms and are unconventional for HelpDot documentation.
• In the Workspace Admins article, the section "How Workspace management continues to improve in New Expensify" contains only a single sentence and an external link. This is thin for a standalone section and could be folded into the introductory text or another section.

Recommendations

1. Fix capitalization: Change "workspace members" to "Workspace members" in the FAQ question in the Workspace Admins article (line 97 area).
2. Evaluate emoji usage: Consider replacing the emoji symbols with plain text descriptions (e.g., "a green dot on actions to take, and a red dot on errors to review") for consistent rendering.
3. Consider consolidating thin section: The "How Workspace management continues to improve" section in the Admins article is only one sentence. Consider merging it into the intro or removing it, since linking to an external blog for future updates may become stale.
4. External links: Both articles link to expensify.storylane.io for interactive tours. These are external URLs — verify these will remain stable and accessible long-term.

Files Reviewed

• docs/articles/new-expensify/getting-started/Coming-from-Expensify-Classic-for-Submitters-and-Approvers.md — Strong migration guide for end users. Well-structured with effective tables and cross-links. Minor emoji concern in FAQ.
• docs/articles/new-expensify/getting-started/Coming-from-Expensify-Classic-for-Workspace-Admins.md — Strong admin-focused migration guide. One capitalization fix needed, one thin section to consider consolidating.

Note: Review based on governance files HELPSITE_NAMING_CONVENTIONS.md, HELP_AUTHORING_GUIDELINES.md, and TEMPLATE.md.

[stephanieelliott]

Ok. ready for review now @brianlee-expensify!

[melvin-bot]

@brianlee-expensify looks like this was merged without a test passing. Please add a note explaining why this was done and remove the Emergency label if this is not an emergency.

[github-actions]

HelpDot Documentation Review

Overall Assessment

This PR adds two new migration guide articles for users transitioning from Expensify Classic to New Expensify -- one targeting submitters and approvers, and one targeting Workspace Admins. Both articles are well-structured, clearly written, and serve a genuine user need. The comparison table format is effective for orientation-style content. A few governance compliance items should be addressed.

Scores Summary

• Readability: 9/10 - Excellent scannability through consistent table formatting, clear prose, and logical flow. The comparison tables and task-mapping tables make it easy to find equivalent workflows. Bullet lists in the benefits section are well-structured.
• AI Readiness: 8/10 - Both articles include complete YAML metadata with internalScope, task-based "How to..." headings, and realistic keywords. Minor concern: these articles cover multiple workflows (expenses, reports, approvals, cards, reimbursements) rather than a single workflow, which could reduce retrieval precision per Section 1 and Section 6 of the authoring guidelines. However, the "migration guide" framing is a reasonable use case for broader coverage.
• Style Compliance: 8/10 - UI elements are consistently bolded, the three dots menu follows the exact required format, and tab/button names appear to match UI conventions. One capitalization issue found (see Key Findings).

Key Findings

Issues to address:

• In the Workspace Admins article, the final FAQ uses lowercase "workspace members" -- this should be "Workspace members" with a capital W to match the established UI terminology used consistently elsewhere in both articles.
• Both articles link to external storylane.io URLs using full absolute URLs. The cross-linking standards state "Use relative links only" and "Do not use full URLs." While these are external links (not internal HelpDot cross-links), it is worth confirming whether the governance intent applies to external URLs or only internal cross-references.
• The authoring guidelines require "one primary workflow per article." These migration guides inherently cover multiple workflows. This is a reasonable editorial choice for orientation content, but be aware it may reduce AI retrieval precision for specific task queries.

Positive aspects:

• YAML frontmatter is complete on both articles, including well-scoped internalScope fields that clearly define audience and exclusions.
• The three dots menu reference in the Submitters article correctly follows the mandated format: "select the three dots (⋮)".
• All ## headings are task-based and start with "How" or "What" -- fully compliant with heading rules.
• Cross-link anchor text consistently uses the "Learn how to..." / "Learn more about..." descriptive pattern required by the guidelines.
• The articles are intentionally split by audience (submitters/approvers vs. admins), which aligns with the guideline to separate admin and member flows.
• FAQ questions are phrased as user questions starting with appropriate question words.

Recommendations

1. Fix capitalization: Change "workspace members" to "Workspace members" in the last FAQ of the Workspace Admins article.
2. Verify external link policy: Confirm whether the "relative links only" rule in the cross-linking standards is intended to apply to external URLs (storylane.io) or only to internal HelpDot article references.
3. Consider retrieval impact: These articles are broad by design. If AI retrieval surfaces them too frequently for specific task queries, consider adding more targeted keywords or adjusting internalScope to help retrieval systems distinguish these guides from dedicated feature articles.

Files Reviewed

• docs/articles/new-expensify/getting-started/Coming-from-Expensify-Classic-for-Submitters-and-Approvers.md -- New file. Well-structured migration guide with strong readability. Minor: inherently multi-workflow.
• docs/articles/new-expensify/getting-started/Coming-from-Expensify-Classic-for-Workspace-Admins.md -- New file. Well-structured admin migration guide. Fix: lowercase "workspace" in final FAQ answer.

Note: Detailed line-by-line feedback has been provided as inline comments.

[OSBotify]

🚀 Deployed to staging by https://github.com/brianlee-expensify in version: 9.3.83-0 🚀

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

Bundle Size Analysis (Sentry):

• Android
• iOS

[OSBotify]

🚀 Deployed to production by https://github.com/mountiny in version: 9.3.83-3 🚀

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