[No QA] Docs updates for E/A#99995 bulk submit skips blocked reports

[MelvinBot]

Explanation of Change

Documents the bulk submit behavior shipped in #99995, which changed how a mixed selection of reports is handled on the Reports tab.

Before that PR, selecting several reports and choosing Submit evaluated the held / pending-card guards against the flattened list of transactions across every selected report, so a single blocked report could silently change the outcome for the whole selection. Now each report is evaluated on its own: submittable reports are submitted, blocked reports are skipped, and a Submit reports window lists the reports that were skipped.

The help site only described this for a single report ("Why can’t I submit a report when all expenses are on hold?"), and never covered submitting several reports at once, so a member who saw the new window had nothing to search for.

Changes, all in docs/articles/new-expensify/reports-and-expenses/Create-and-Submit-Reports.md:

• Added How to submit multiple expense reports at once, with separate web and mobile navigation.
• Added What happens when some of the selected reports can’t be submitted, covering the skip behavior, the Submit reports window and its message, the Got it button, and the Mark reports as done title and message used on workspaces without an approval workflow.
• Added the FAQ entry Why weren’t all of the reports I selected submitted?
• Updated keywords and internalScope to cover the bulk submit workflow.

UI labels used here were checked against the live web app (Spend navigation tab, Expense reports section, Reports tab, the selected-count button that reads for example 2 selected) and against src/languages/en.ts for the window strings (Submit reports, Mark reports as done, These reports couldn't be submitted. Check that expenses aren't held or pending, then try again., These reports couldn't be marked as done. Check that expenses aren't held or pending, then try again., Got it).

The mobile navigation step (In the navigation tabs on the bottom, tap **Spend** > **Reports**.) and the long-press selection steps mirror the already-published steps in Duplicate a Report — the narrow Spend page shows a flat tab strip (Reports, Expenses, Drafts) with no Expense reports heading, so the two-step web-style navigation does not apply there.

No product code is changed — this is a help site (HelpDot) documentation update only.

Fixed Issues

$ #99995
PROPOSAL:

Tests

Documentation-only change. No tests.

Offline tests

Documentation-only change. There is no offline behavior to test.

QA Steps

Documentation-only change. No tests.

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

---

@c3024, 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.

[c3024]

@MelvinBot please make these changes to the article and the PR body.

1. In "How to submit multiple expense reports at once", the mobile steps are wrong. The narrow Spend page shows a flat tab strip (Reports, Expenses, Drafts) and has no "Expense reports" heading. Replace mobile steps 1 and 2 with a single step matching the Duplicate a Report article:

   1. In the navigation tabs on the bottom, tap Spend > Reports.

   Renumber the remaining mobile steps.

2. In "What happens when some of the selected reports can't be submitted", extend the final note. When the workspace has no approval workflow the message changes too, not only the title. Use:

   Note: If your workspace does not use an approval workflow, the window is titled Mark reports as done and the message reads These reports couldn't be marked as done. Check that expenses aren't held or pending, then try again.

3. In the PR body, replace the TODO placeholder lines and the JS console checkbox in the Tests and QA Steps sections with a docs-only note, for example "Documentation-only change. No tests."

Everything else reflects the current behavior.

[MelvinBot]

⚠️ A setup step failed before I could start. This is usually a temporary issue — try again in a few minutes, and if it persists post in #melvinbot-ai.

Run details

[c3024]

@MelvinBot please make these changes to the article and the PR body.

1. In "How to submit multiple expense reports at once", the mobile steps are wrong. The narrow Spend page shows a flat tab strip (Reports, Expenses, Drafts) and has no "Expense reports" heading. Replace mobile steps 1 and 2 with a single step matching the Duplicate a Report article:

   1. In the navigation tabs on the bottom, tap Spend > Reports.

   Renumber the remaining mobile steps.

2. In "What happens when some of the selected reports can't be submitted", extend the final note. When the workspace has no approval workflow the message changes too, not only the title. Use:

   Note: If your workspace does not use an approval workflow, the window is titled Mark reports as done and the message reads These reports couldn't be marked as done. Check that expenses aren't held or pending, then try again.

3. In the PR body, replace the TODO placeholder lines and the JS console checkbox in the Tests and QA Steps sections with a docs-only note, for example "Documentation-only change. No tests."

Everything else reflects the current behavior.

[MelvinBot]

⚠️ A setup step failed before I could start. This is usually a temporary issue — try again in a few minutes, and if it persists post in #melvinbot-ai.

Run details

[c3024]

@MelvinBot please make these changes to the article and the PR body.

1. In "How to submit multiple expense reports at once", the mobile steps are wrong. The narrow Spend page shows a flat tab strip (Reports, Expenses, Drafts) and has no "Expense reports" heading. Replace mobile steps 1 and 2 with a single step matching the Duplicate a Report article:

   1. In the navigation tabs on the bottom, tap Spend > Reports.

   Renumber the remaining mobile steps.

2. In "What happens when some of the selected reports can't be submitted", extend the final note. When the workspace has no approval workflow the message changes too, not only the title. Use:

   Note: If your workspace does not use an approval workflow, the window is titled Mark reports as done and the message reads These reports couldn't be marked as done. Check that expenses aren't held or pending, then try again.

3. In the PR body, replace the TODO placeholder lines and the JS console checkbox in the Tests and QA Steps sections with a docs-only note, for example "Documentation-only change. No tests."

Everything else reflects the current behavior.

[MelvinBot]

⚠️ A setup step failed before I could start. This is usually a temporary issue — try again in a few minutes, and if it persists post in #melvinbot-ai.

Run details

[c3024]

@MelvinBot update the PR based on the discussions so far.

[MelvinBot]

All three changes are in, pushed as f005b18.

1. Mobile steps — replaced steps 1 and 2 with the single step from Duplicate a Report, and renumbered the rest: Create-and-Submit-Reports.md:47-52

1. In the navigation tabs on the bottom, tap Spend > Reports.

2. No-approval-workflow note — now covers the message as well as the title: Create-and-Submit-Reports.md:71

Note: If your workspace does not use an approval workflow, the window is titled Mark reports as done and the message reads These reports couldn’t be marked as done. Check that expenses aren’t held or pending, then try again.

I confirmed that string against src/languages/en.ts:1691 (reportsNotMarkedAsDoneDescription) before writing it.

3. PR body — the TODO placeholders and the JS console checkboxes in Tests and QA Steps are replaced with Documentation-only change. No tests. I also updated the Explanation of Change so it describes the corrected mobile navigation and the extended note instead of the old two-step mobile flow.

Typography note

The article uses curly apostrophes throughout (couldn’t, aren’t), so I matched that in the new note rather than the straight apostrophes in your comment. The en.ts source string itself uses straight apostrophes — that difference is only in the rendered doc prose, which is already inconsistent with en.ts in the existing Submit reports line above it.

Two caveats worth flagging:

• I could not verify this in a browser — web setup failed on this run, so the change is based on the article source, en.ts, and the published Duplicate a Report steps rather than a live check.
• The repo's lint and spell-check commands were blocked in this environment, so npm run spell-changed and prettier did not run. The edit is prose-only with no new or unusual words, so I expect CI to be clean, but it is unverified.

Once the HelpDot preview redeploys, the updated article will be at the preview link from the earlier deploy comment.

[c3024]

@MelvinBot mark the PR as ready for review.

[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 @jliexpensify

[melvin-bot]

@jliexpensify 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]

Done — the PR is out of draft and ready for review.

PullerBear has already picked up the hand-off and requested stephanieelliott as the reviewer.

One thing needs you: the PR Author Checklist in the body is still entirely unchecked. I can't tick those boxes for you — most are human sign-offs about testing on each platform — and Check independent approval will stay red until a reviewer signs off. Please work through the checklist so the merge gates can clear.

Check status on f005b185 — everything green except the expected pre-review gates:

Check	Status
spellcheck	✅ pass
build (HelpDot)	✅ pass
check / validate / verify / verifySignedCommits	✅ pass
CLA	✅ pass
Check independent approval	❌ fail — expected until a reviewer approves

The spellcheck pass also clears the caveat I flagged on my last comment: I couldn't run npm run spell-changed locally, but CI ran it against this commit and it's clean.

Updated preview: Create and Submit Reports — worth a quick read to confirm the mobile step and the extended Mark reports as done note render the way you expect.

I still could not verify anything in a browser on this run, so the article content remains checked against the source, en.ts, and the published Duplicate a Report steps rather than a live app.

[github-actions]

HelpDot Documentation Review

Overall Assessment

This PR documents the new bulk-submit behavior from #99995 in Create-and-Submit-Reports.md. It adds two task-based ## sections, an FAQ entry, and updates keywords/internalScope. The additions are high quality and closely aligned with the governance files. Scores below reflect only the proposed changes (the diff), not pre-existing content.

Scores Summary

• Readability: 9/10 - Clear, scannable steps with separate web/mobile navigation, bolded labels, and helpful "Note" callouts. Benefit-focused intro sentences.
• AI Readiness: 9/10 - Both new headings are task/question-based; keywords and internalScope updated to real search phrasing; screenshot placeholder uses the correct non-rendered HTML-comment format with a specific Purpose.
• Style Compliance: 9/10 - UI labels bolded and verified against src/languages/en.ts (Submit reports, Mark reports as done, Got it, and the exact window messages). Navigation phrasing follows conventions; FAQ entry is correctly question-based under # FAQ.

Key Findings

• Strong adherence to task-based heading rules: ## How to submit multiple expense reports at once and ## What happens when some of the selected reports can't be submitted.
• UI terminology is exact and bolded, matching the live app and en.ts strings — no paraphrasing or invented synonyms.
• Web vs mobile navigation is correctly split (they genuinely differ on the narrow Spend page), consistent with the naming conventions.
• The screenshot suggestion follows the required format and gives a specific, non-generic Purpose.
• FAQ addition follows the question-based structure and is placed under the existing # FAQ.
• Minor: the new mobile nav step In the navigation tabs on the bottom, tap **Spend** > **Reports**. differs stylistically from the unified parenthetical form used elsewhere in the article; acceptable here since the flows differ, but worth a consistency pass.

Recommendations

• No blocking issues in the proposed changes. Optional: confirm the mobile long-press / Select wording matches the current app exactly, as this is the one area not backed by an en.ts string.
• Consider whether "submit reports window" in keywords is descriptive vs UI-exact (it is descriptive, which is acceptable).

Files Reviewed

• docs/articles/new-expensify/reports-and-expenses/Create-and-Submit-Reports.md — Approve. Additions are well-structured, UI-accurate, and governance-compliant.

Note: This is a summary review of the diff only.

[github-actions]

Vague UI reference: "Select the button that shows how many reports you selected" is descriptive rather than literal. Per the Deterministic Writing and Prohibited Language rules (HELPSITE_NAMING_CONVENTIONS.md), reference the exact UI label. Consider: "Select the selected-count button (for example, 2 selected), then select Submit." Same applies to the mobile step on line 52.

[MelvinBot]

Fixed in 410a306c, though not with the exact wording suggested.

selected-count button isn't a UI label either, so it would trade one vague reference for another. The button's literal label is N selected — see src/languages/en.ts:4813-4816 (one: '1 selected', other: '${count} selected'). Both steps now reference that label directly:

4. Select the X selected button (for example, 2 selected), then select Submit.

4. Tap the X selected button (for example, 2 selected), then tap Submit.

This matches the pattern already used in sibling articles — Track-Taxes.md:51 (Click **X selected** in the top-right menu) and Configure-Per-Diem-in-a-workspace.md:57 (the **X selected** dropdown).

[github-actions]

Navigation label convention: The Navigation Instruction Standards (HELPSITE_NAMING_CONVENTIONS.md) specify the labels Web: and Mobile: for separate platform instructions. Consider using **Web:** / **Mobile:** here (and on line 47) instead of **On web:** / **On mobile:** for consistency with the standard.

[MelvinBot]

Fixed in 410a306c — both labels are now **Web:** and **Mobile:**.

Confirmed against HELPSITE_NAMING_CONVENTIONS.md:105-113, which specifies Web: / Mobile: for separate platform instructions.

Worth flagging for whoever owns the convention: existing articles are split roughly evenly on this, with **On web:** / **On mobile:** actually the more common form today (19 occurrences versus 9 for **Web:** / **Mobile:**). I followed the documented standard here, but the rest of the help site would need a sweep to match.

[c3024]

@MelvinBot address the review comments.

[MelvinBot]

Both review comments addressed in 410a306c. I replied in each thread with the details.

Platform labels — **On web:** / **On mobile:** → **Web:** / **Mobile:**, matching HELPSITE_NAMING_CONVENTIONS.md:105-113.

Vague UI reference — fixed, but not with the reviewer's suggested wording. selected-count button isn't a UI label either, so it swaps one vague reference for another. The literal label is N selected per src/languages/en.ts:4813-4816, so both steps now read:

4. Select the X selected button (for example, 2 selected), then select Submit.

That matches the pattern already used in Track-Taxes.md:51 and Configure-Per-Diem-in-a-workspace.md:57. Shout if you'd rather have the reviewer's exact phrasing.

One thing worth a decision from you: the help site is split on the platform-label convention, and **On web:** / **On mobile:** is currently the more common form (19 occurrences versus 9). I followed the documented standard, but the rest of the articles would need a separate sweep to match.

Verification caveats

Browser verification was unavailable on this run, and the repo's lint and spell commands were blocked in this environment, so npm run spell-changed and prettier did not run. The change is prose-only with no new words, so I expect CI to be clean — but that is unverified. The conventions and the N selected label were both confirmed by reading the source files, not by rendering the page.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f005b185ae

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Scope bulk submission to supported workspace types

This claim also covers free Submit workspaces, but selecting multiple reports when any selected report belongs to a Submit policy hides the Submit action: useSearchBulkActions.ts:2355-2360 permits that policy type only for a single-report selection. Users with two reports from a Submit workspace therefore cannot complete step 4. Add this limitation and direct those users to submit each report individually.

Useful? React with 👍 / 👎.

[MelvinBot]

Addressed in c3119f9a — the limitation is real, but I documented it differently than described here, because the stated scope is wrong.

Confirmed: useSearchBulkActions.ts:2355-2358 gates shouldShowSubmitOption on !doSelectedItemsBelongToSubmitPolicy || hasSingleSubmitPolicySelection. doSelectedItemsBelongToSubmitPolicy is a .some(), so one qualifying report in the selection is enough, and the option is omitted from the menu rather than disabled.

Correction: this is not "free Submit workspaces" as a category of workspaces without approvals. isSubmitPolicy is strictly policy?.type === CONST.POLICY.TYPE.SUBMIT, which is 'submit2026' — the free Submit plan. PERSONAL, TEAM, and CORPORATE are unaffected, so a Collect or Control workspace with no approval workflow bulk-submits fine. Writing the caveat as "workspaces without an approval workflow" would have made the article wrong in the other direction, since the article already uses that phrase for the Mark as done label, which is a different predicate entirely.

So the note names the plan and links the existing Use a Free Submit Workspace article:

Note: Reports on a free Submit workspace must be submitted one at a time. If any report in your selection belongs to a Submit workspace, the Submit option does not appear. Submit those reports individually instead.

Plus a matching FAQ entry, Why don’t I see “Submit” when I select multiple reports?, which also covers the !isOffline gate on the same condition.

One note on framing: the restriction predates this work. It came from [Submit] Submit button with manager email prompt take 2, not from Warn about blocked reports when bulk submitting a mixed selection, whose diff does not touch this condition. The reason for the single-report limit is visible at useSearchBulkActions.ts:2423-2454: Submit-plan reports route through a manager-email popover that only handles selectedReports.at(0).

Verified statically only — browser verification was unavailable on this run.

[jliexpensify]

I think melvin might be getting too much into the weeds here?

[stephanieelliott]

Yea I agree

[c3024]

@MelvinBot check codex comment and address it.

[MelvinBot]

Nothing to fix — there is no broken check. Every automated check on this PR passes. The single failure is Check independent approval, which just means nobody has approved yet.

The failing job logs it plainly:

Insufficient independent peer review {
  approvers: [],
  independentApprovers: [],
Expensify/App#101261 does not have enough independent eligible reviewer approvals.

That is an approval gate, not a code or build problem. All five existing reviews on the PR are COMMENTED (from github-actions, MelvinBot, and chatgpt-codex-connector) — zero are APPROVED.

What it takes to clear it: an approval from an eligible reviewer who isn't an author of the PR. The check will re-run and pass on its own once that lands. I'm not pushing a commit, because no commit can satisfy this check.

Full check status

Check	State
build (Deploy ExpensifyHelp)	✅ SUCCESS
spellcheck	✅ SUCCESS
validate	✅ SUCCESS
verify	✅ SUCCESS
verifySignedCommits	✅ SUCCESS
check	✅ SUCCESS
checklist	✅ SUCCESS
CLA / CLA	✅ SUCCESS
Request reviewers for new Onyx.connectWithoutView calls	✅ SUCCESS
Check independent approval	❌ FAILURE (no approvals)
actionlint, approveAndMerge, validateSchemas, validateImmutableActionRefs, Warn deployers if Expensify Help deploy failed	⏭️ SKIPPED

build was still in progress when this request came in — it has since finished green, so the docs change itself builds and deploys fine.

---

view run

[MelvinBot]

Codex found a real gap, but scoped it wrong. Documented it correctly in c3119f9a, and I replied in its thread with the details.

What Codex got right: selecting 2+ reports hides the bulk Submit option entirely when any selected report is on a Submit-plan workspace, so step 4 is unreachable for those users. useSearchBulkActions.ts:2355-2358 gates on !doSelectedItemsBelongToSubmitPolicy || hasSingleSubmitPolicySelection, and that flag is a .some() — one qualifying report in a mixed selection is enough.

What it got wrong: it called this "free Submit workspaces" in the sense of workspaces without approvals. isSubmitPolicy is strictly type === CONST.POLICY.TYPE.SUBMIT = 'submit2026', the free Submit plan. Collect and Control workspaces with no approval workflow bulk-submit fine. Had I written the caveat Codex's way, it would have collided with the article's existing "no approval workflow" sentence about Mark as done, which is a completely different predicate, and made the article wrong for far more users than it fixed.

So the article now names the plan and links the existing Use a Free Submit Workspace article:

Note: Reports on a free Submit workspace must be submitted one at a time. If any report in your selection belongs to a Submit workspace, the Submit option does not appear. Submit those reports individually instead.

I also added the FAQ entry Why don’t I see “Submit” when I select multiple reports? covering the same limitation plus the !isOffline gate on that condition, and extended keywords.

Two things I found while verifying — your call, I did not change them

Both concern the pre-existing Mark as done note you already signed off on, so I left it alone rather than silently reopening approved copy.

1. The note is broader than the code. "If your workspace does not use an approval workflow, you'll see Mark as done instead of Submit" — shouldShowMarkAsDone additionally requires the user to be a track-intent user, the report owner, and their own next approver. A non-track-intent user on an approval-free workspace still sees Submit. Policy type is irrelevant to this one.

2. Mixed selections hide the action for track-intent users. useSearchBulkActions.ts:2364 requires allReportsShouldMarkAsDone || noReportsShouldMarkAsDone, so a selection mixing mark-as-done and submit reports shows neither label. Not currently documented.

Say the word if you want either written up.

Worth knowing for the PR framing: this restriction is not new behavior from Warn about blocked reports when bulk submitting a mixed selection — that diff never touches this condition. It came from [Submit] Submit button with manager email prompt take 2 back in June, because Submit-plan reports route through a manager-email popover that only handles one report.

Everything above is from reading the source and its tests. Browser verification was unavailable on this run, so I could not watch the menu render for a two-report Submit-workspace selection — that is the one claim a live check would settle.

[OSBotify]

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

Updated articles:

• articles/new-expensify/reports-and-expenses/Create-and-Submit-Reports

[jliexpensify]

LGTM

[OSBotify]

🚀 Deployed to staging by https://github.com/stephanieelliott in version: 9.4.95-0 🚀

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

[OSBotify]

🚀 Deployed to production by https://github.com/Julesssss in version: 9.4.95-4 🚀

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