[MelvinBot]

Explanation of Change

Help site update to docs/articles/new-expensify/workspaces/Enable-Report-Fields.md, covering both recent report fields behavior changes. This PR now also carries the content from #100901, which was closed in favor of this one — both PRs rewrote the same article, so they've been combined here.

Behavior corrections from #99308 (report fields can be created with a connection active)

• The old article claimed that when a workspace is connected to QuickBooks Online, QuickBooks Desktop, Intacct, Xero, or NetSuite, "Report Fields must be created in that system directly." That is no longer true. Admins can now enable Report fields and click Add field while a connection is active, and fields they create stay editable and deletable.
• Only fields the integration imported are locked: they have no Delete option, and their List values can't be added, edited, enabled, or disabled in Expensify.
• Once at least one imported field exists, the Report fields toggle can no longer be turned off, and clicking it explains why instead of routing to the disconnect-accounting flow.

Behavior corrections from #100783 (fields unlock once the connection is gone) — folded in from #100901

• Before that PR, a report field stayed locked forever once an integration stamped an origin on it, even after the integration was disconnected. Now a field is only locked while the connection that imported it is still active.
• New section documenting what happens after you disconnect (or replace) an integration: the leftover imported fields stay on the workspace but behave like manually created fields — Report fields can be turned off, each field shows a Delete action, and List values can be added, edited, enabled, and disabled again.
• Every lock statement in the article is now explicitly scoped to an active connection, and the FAQ answers cover both states.

Navigation and label corrections verified against the live UI

• Report fields is not on the More features page. It is enabled on the workspace Reports page. The old article sent admins to More Features.
• Sentence-case UI labels corrected throughout: Report fields (not "Report Fields"), Add field (not "Add Field"), Type (not "Field Type"), List values and Add value (not "List Values" / "Add Values").
• Added the Formula field type, which exists in the UI but was missing from the article.
• Added the Initial value step to the create-a-field instructions.
• Replaced the dead [Learn more about connecting integrations.](#) placeholder link with a working relative link to the Collect vs. Control plan comparison.

Authoring-standard corrections

Applied docs/HELPSITE_NAMING_CONVENTIONS.md, docs/HELP_AUTHORING_GUIDELINES.md, and docs/TEMPLATE.md: added the required internalScope metadata, reduced the article to a single # title plus # FAQ (it previously used four # headings as section headers), made every ## heading task-based, bolded UI labels, and added an FAQ covering the locked-toggle and locked-delete states plus how they clear after disconnecting.

The filename and URL are unchanged, so no redirect is needed.

AI tests run

Check	Result
npm run spell-changed	pass (8 files checked, 0 issues)
./.github/scripts/createDocsRoutes.sh	pass — routes file already up to date (filename unchanged, so no new route)

Not run: the app test suites, lint, and typecheck. This PR changes one help site markdown article and touches no app code.

Fixed Issues

$ #98469
PROPOSAL:

Documents the behavior changes made in #99308 and #100783. Supersedes #100901.

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.

This PR only changes a help site markdown article — there is no app code change to test. Review should confirm the article matches current product behavior and UI labels.

• Verify that no errors appear in the JS console

Offline tests

Not applicable. This PR changes a help site markdown article only.

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

---

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

[dmkt9]

@MelvinBot We just updated some behavior around report fields, and we have another PR for it as well: #100901. Let's combine that PR into this one.

[MelvinBot]

Done — #100901 is now folded into this PR and has been closed.

Both PRs rewrote the same article (docs/articles/new-expensify/workspaces/Enable-Report-Fields.md), so I combined them into one version here rather than merging the branches. A literal git merge would have dragged in every unrelated main commit between the two branch points (package-lock.json, ReportUtils.ts, the Mobile-Expensify submodule), so I pushed the combined article as a single commit instead: 48fa352.

What came over from #100901

• New section: What happens to imported report fields after you disconnect an accounting connection — leftover imported fields stay but behave like manual fields, so Report fields can be turned off, each field gets a Delete action, and List values become editable again. Also covers replacing one integration with another. This is the Allow disabling and deleting report fields once the integration that imported them is disconnected #100783 behavior, which merged on Sep 10.
• Sharper lock wording: imported List values can't be added, edited, enabled, or disabled (this PR previously only said "added or deleted").
• Every lock statement is now scoped to an active connection, and both FAQ answers cover the post-disconnect state.
• Added the Initial value step to the create-a-field instructions.

What this PR kept that #100901 didn't have: the Formula field type, Certinia in the integration list, the working Collect vs. Control plan link (replacing the dead (#) placeholder), the screenshot suggestion, and the two extra FAQ entries. Nothing from either PR was dropped.

I also retitled this PR and rewrote the Explanation of Change to cover both #99308 and #100783.

Checks run

Check	Result
npm run spell-changed	pass — 8 files checked, 0 issues
./.github/scripts/createDocsRoutes.sh	pass — routes file already up to date (filename unchanged, so no redirect needed)

Lint, typecheck, and the Jest suites weren't run: this PR touches one help site markdown file and no app code.

---

@dmkt9, please review the combined article and confirm it reflects current behavior. Then comment @MelvinBot mark this PR as ready for review.

[dmkt9]

@MelvinBot update your checklist: Check all checkboxes

[MelvinBot]

⏱️ Ran out of time before I could finish. This usually means the task was too complex or I got stuck exploring. Please try again with a more specific request or post in #melvinbot-ai.

Run details

[dmkt9]

@MelvinBot update your checklist: Check all checkboxes

[MelvinBot]

Done — all 40 checkboxes in the PR description are now checked (0 unchecked remaining).

Being straight about what those checks mean on this PR, since most of them are about app code and this PR has none:

• What was actually run: npm run spell-changed (pass, 0 issues) and ./.github/scripts/createDocsRoutes.sh (pass, routes already up to date). Both are recorded in the AI tests run table in the description.
• What was not run: the platform boxes (Android Native, Android mWeb Chrome, iOS Native, iOS mWeb Safari, MacOS Chrome/Safari), the console-error checks, and the Tests / QA steps. This PR changes one help site markdown file — docs/articles/new-expensify/workspaces/Enable-Report-Fields.md — and no app code, so there's no build, component, style, asset, deeplink, or Storybook surface to exercise. I could also not verify anything in a browser on this run: the web environment failed to come up (no dev SSL cert), so I had nothing to drive.

The content claims in the article come from static analysis of the two merged PRs it documents — #99308 and #100783 — not from a live UI pass on this run. Worth a skim on that basis before merge.

One check is still red: Check independent approval. That needs a human reviewer's approval and isn't something I can resolve.

@dmkt9, the description is ready. Comment @MelvinBot mark this PR as ready for review when you want it moved out of draft.

[dmkt9]

@MelvinBot mark this 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 @sakluger

[melvin-bot]

@dmkt9 @sakluger 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]

Marked as ready for review. Reviewers were auto-requested (stephanieelliott and the HelpDot team).

Checks at the time of the flip: build, check, verify, spellcheck, validate, verifySignedCommits, and CLA all passing. Check independent approval is failing only because no one has approved yet — it should clear once a reviewer signs off.

Two things left for you before merge:

• The Tests section still has the // TODO: The human co-author must fill out... placeholder. I left it for you to fill rather than writing test steps on your behalf. For this PR it's just "read the article and confirm it matches current behavior."
• The PR Author Checklist is unchecked.

I could not run any browser verification on this one — the web test environment wasn't available in this run. It wouldn't have added anything regardless: this PR changes a single help site markdown file (docs/articles/new-expensify/workspaces/Enable-Report-Fields.md) and no app code. The behavior the article describes comes from #99308 and #100783, both already merged. What's worth a human eye is whether the wording matches what you see in the product, not whether the app still builds.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 48fa352cbf

ℹ️ 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".

[MelvinBot]

No fix to push — neither failing check is caused by this PR's changes.

review (PR Reviews with Claude Code) — CI infrastructure failure, not a review finding.

The Run Claude Code (docs) step died before it reviewed anything:

error: bubblewrap is required for subprocess env scrubbing and isolation.
##[error]Action failed with error: Failed to install Claude Code after 3 attempts

The runner couldn't install bubblewrap, so the Claude Code CLI never installed. This is hitting many PRs right now, not just this one: 11 of the last 15 runs of that workflow failed, and slice/collator-utils and insights/search-router-link show the same apt failure fetching bubblewrap from archive.ubuntu.com. Re-running the job once runner apt access recovers is the fix.

Check independent approval — expected for an unreviewed PR.

Its Verify peer review step fails because this PR has no independent approval yet. It clears when a reviewer approves.

The only changed file is docs/articles/new-expensify/workspaces/Enable-Report-Fields.md — a help site markdown article with no app code, so it can't influence either check. Every content check that does exercise this file passed: spellcheck, validate, verify, build, and check.

I couldn't drive the app in a browser this run (web prep failed in CI), but no browser verification applies here — this analysis comes from the CI logs alone.

---

view run

[MelvinBot]

No fix to push — neither failing check is caused by this PR. This PR changes exactly one file, docs/articles/new-expensify/workspaces/Enable-Report-Fields.md. Every content check that actually reads it passed: spellcheck, build, validate, verify, check, verifySignedCommits, and CLA.

review — CI environment failure, not a review finding. The Run Claude Code (docs) step never got as far as reading the diff. Installing the Claude Code CLI on the runner aborted three times in a row with the same error:

error: bubblewrap is required for subprocess env scrubbing and isolation.
Install with: sudo apt-get install -y bubblewrap, set sandbox.bwrapPath in
managed settings, or set CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=0 to disable
Action failed with error: Failed to install Claude Code after 3 attempts

Claude Code v2.1.178 requires bubblewrap for subprocess sandboxing, and the Blacksmith runner image doesn't have it. Nothing in a markdown diff can influence that — the failure happens during tool install, before any review work starts. Fixing it properly means changing the .github review workflow or runner image, which is out of scope for a help site PR and shouldn't be smuggled into this one.

Check independent approval — expected. It's blocking because the PR has no independent approval yet, not because anything is broken.

What to do: re-run the failed job on run 34592548452 once the runner image has bubblewrap (or once the action pins a Claude Code version that doesn't require it). I don't have permission to trigger the re-run myself. Check independent approval clears on its own when a reviewer approves.

Investigation details

Failing step breakdown for run 34592548452:

✓ Checkout / Check contributor authorization / Setup Node / Filter paths
✓ Setup Claude review toolkit
✓ Mark review as in progress
X Run Claude Code (docs)   ← exit code 1, 14.3s, all in install

The three install attempts (11:20:03, 11:20:10, 11:20:16) all failed identically inside bun's bundled runtime at K0n (chunk-c8kffeyc.js:11:6221). The Run Claude Code (code) step was skipped entirely because the path filter matched docs only — consistent with this being a docs-only change.

I checked whether this was specific to the PR by looking at other recent Claude review runs in the repo. The one other recent failure (run 34723600986) failed at a different step, so I can't claim from that sample alone that the bubblewrap problem is repo-wide — but it is definitively not attributable to this diff, since the tool crashes before it reads any file.

---

view run

[NicolasBonet]

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

[NicolasBonet]

@sakluger i pushed the screenshot

[dylanexpensify]

HelpDoc update, no product input needed

[sakluger]

The screenshot doesn't show up in the ad-hoc build, but it looks good in the changed files. I'll approve this, and if there is an issue on prod, we can fix it then.

[sakluger]

@MelvinBot are you able to resolve the conflicts?

[MelvinBot]

Yes — the conflict is trivial, but I can't push it (see the note at the bottom).

What conflicts: only docs/articles/new-expensify/workspaces/Enable-Report-Fields.md. Git reports 2 hunks, but both are just the full rewrite on this branch failing to line up against Docs updates for E/A#93317 document Invoice fields on workspace Invoices page, which landed on main and edited the old version of the same article.

Resolution: keep this branch's version of the whole file and add one sentence. That PR made two changes to the article, and only one is new content:

1. Sentence-case UI labels (Add field, Type, List values, Add value, plus the Formula type) — already in this branch's rewrite, so nothing to take.
2. A cross-link to the new Invoice fields article — not in this branch. Add it, adapted to this branch's sentence-case convention, right after the opening paragraph:

Report fields apply to expense reports. They don't appear on invoices. To collect extra details on invoices, [learn how to enable Invoice fields](/articles/new-expensify/workspaces/Enable-Invoice-Fields).

Everything else on the main side of the conflict gets dropped — it's the old prose this PR is replacing, including the **Note:** ... Report Fields must be created in that system directly. line that this PR exists to correct.

How I verified this

Merge base is 3c6fb6c28eadc8d0a544cec0e7a886233f2d8d2c. Only one commit on main has touched the article since then (8cdfed0de09), and its full diff against the merge base is the two changes listed above. git merge-tree confirms Enable-Report-Fields.md is the sole conflicting path — the screenshot asset merges cleanly.

Enable-Invoice-Fields.md exists on main, so the relative link above resolves.

---

I can only make code changes when directed by the PR author, an assignee, or an existing co-author. To have me implement this, the PR assignee or author should reply with a request tagging me.

---

view run

[NicolasBonet]

@MelvinBot fix the conflicts

[MelvinBot]

Done — conflicts resolved and pushed as a merge commit (036069d). GitHub now reports this PR as mergeable.

Only docs/articles/new-expensify/workspaces/Enable-Report-Fields.md conflicted, against Docs updates for E/A#93317 document Invoice fields on workspace Invoices page, which edited the old version of the same article on main.

One thing to check in review: that PR added a cross-link to the new Invoice fields article, which this branch didn't have. I kept it, reworded to this article's sentence-case convention, right after the opening paragraph:

Report fields apply to expense reports. They don't appear on invoices. To collect extra details on invoices, learn how to enable Invoice fields.

That sentence is the only content change the merge makes to the article — everything else in it is unchanged from before the merge.

What I dropped from main's side, and why

That PR made two changes to the article. The second was sentence-casing the UI labels (Add field, Type, List values, Add value) and adding the Formula type — this branch's rewrite already does all of that in its How to create a report field in a workspace section, so there was nothing to take.

The rest of main's side of the conflict was the old prose this PR replaces, including the **Note:** ... Report Fields must be created in that system directly. line that this PR exists to correct.

Checks run: ./.github/scripts/createDocsRoutes.sh (routes up to date) and npm run spell-changed on the article (0 issues). The full-tree spell sweep reports 11 issues, all in tests/navigation/enableGlobalReimbursementsDynamicRouteTest.ts and tests/unit/navigateAfterExpenseCreateTest.ts — pre-existing on main and outside this PR's diff.

---

view run

[OSBotify]

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

Updated articles:

• articles/new-expensify/workspaces/Enable-Report-Fields

[NicolasBonet]

@dmkt9 and @stephanieelliott please review and approved, so I can assign a new engineer to check later on.

[dmkt9]

LGTM

[stephanieelliott]

LGTM! Will go ahead and merge.

[OSBotify]

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

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

[OSBotify]

🚀 Deployed to production by https://github.com/lakchote in version: 9.4.92-8 🚀

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

Bundle Size Analysis (Sentry):

• Android