Remove rulesRevamp beta.

[Krishna2323]

Explanation of Change

Fixed Issues

$ #97686
$ #98699
PROPOSAL:

Tests

1. Rules

1. On a non-beta account, open Workspace → Rules.
2. Verify the revamped tabbed page appears: General, Card restrictions, Expense defaults, Require fields, Flag for review.
3. Open each tab and add/edit a rule. Verify there are no blank or Not Found pages.

2. Workflows

4. Open Workspace → Workflows.
5. Verify the revamped tabs: Submissions, Approvals, Payments, Advanced.
6. As a read-only member, verify Workflows still shows the read-only state.

3. Smart Limit deep link

7. Disable Approvals in Workflows settings > go to Expensify Card → Issue new card → Limit type and click the disabled-description link.
8. Verify it opens Workflows on the Approvals tab.
9. Repeat from an existing card's Limit type.

4. Categories

10. Go to Categories → ⋮ and verify the old Settings option is gone.
11. Open a category and verify only the revamped rule rows are shown. No legacy rows like Flag amounts over, Require receipts over, or Required fields.

5. Tags

12. Go to Tags → ⋮ → Settings and verify Require tags and Track billable are gone.
13. For independent multi-level tags, verify there's no Required column or detail-page Required toggle.
14. Go to Rules → Require fields and verify per-level Required rows work.

6. Final regression sweep

15. On a non-beta account, check Workspace overview → More features → Categories → Tags → Workflows → Rules → Expensify Card and the Rules sub-pages.
16. Verify there are no pre-revamp screens or Not Found pages.

• Verify that no errors appear in the JS console

Offline tests

• Same as tests

QA Steps

• Same as tests

• 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
  • MacOS: Desktop
• 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 verified there are no new alerts related to the canBeMissing param for useOnyx
• 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

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

Monosnap.screencast.2026-08-21.12-57-45.mp4

[melvin-bot]

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

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0489bafb3c

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[codecov]

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines	Coverage Δ
src/CONST/index.ts	91.52% <ø> (ø)
...s/Search/SearchRouter/useNavigationSuggestions.tsx	92.15% <ø> (ø)
...ables/WorkspaceTagsTable/WorkspaceTagsTableRow.tsx	90.32% <100.00%> (-0.31%)	⬇️
src/components/Tables/WorkspaceTagsTable/index.tsx	69.23% <ø> (-1.68%)	⬇️
src/libs/AttendeeUtils.ts	79.31% <ø> (+13.59%)	⬆️
src/libs/CategoryUtils.ts	83.49% <ø> (+7.38%)	⬆️
src/libs/PolicyUtils.ts	81.24% <100.00%> (-0.03%)	⬇️
src/libs/SearchUIUtils.ts	71.82% <100.00%> (ø)
src/libs/actions/Policy/Policy.ts	70.90% <ø> (-0.34%)	⬇️
src/libs/actions/Policy/Tag.ts	68.19% <ø> (+4.29%)	⬆️
... and 53 more
... and 24 files with indirect coverage changes

[JmillsExpensify]

LGTM though no product review required.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Hooray!

Reviewed commit: 3b1bbfd304

ℹ️ 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]

Review — remove rulesRevamp beta

LGTM overall. This is a clean, mechanical beta removal that keeps the "beta on" path everywhere. Verified static consistency + a web smoke test; one non-blocking cleanup worth deciding on before merge.

What I verified ✅

• No leftovers: zero remaining references to RULES_REVAMP / rulesRevamp / isRulesRevampEnabled / isRevamp anywhere in src or tests.
• No orphaned imports/helpers: every removed symbol (formatRequiredFieldsTitle, formatRequireReceiptsOverText, isAttendeeTrackingEnabled, navigateToCategoriesSettings, setPolicyRequiresTag, setPolicyProhibitedExpense, the titleKey props, etc.) has 0 remaining usages in its file. TranslationPaths (SpendRulePageBase.tsx:61) and IconAsset (MerchantRulePageBase.tsx:74) are still used, so they're correctly left in.
• getControlOnlySelectedParts test change is sound: flipping 'rules' → 'perDiem' in CopyPolicySettingsUtilsTest.ts is backed by source — the util derives control-only parts from canPolicyAccessFeature, which now returns true for Collect + Rules, so rules is genuinely no longer Control-only.
• Typecheck: tsc --noEmit reports no errors in the changed areas.
• Web smoke test: the revamped Rules page (General / Card restrictions / Expense defaults / Field requirements / Flag for review / Agents) and the Workflows page both render by default. On a Collect-plan workspace the gated tabs correctly show the Upgrade panel instead of crashing. No visible crashes or error boundaries.

Non-blocking: dead legacy pages left behind 🧹

WorkspaceSplitNavigator now points RULES → PolicyRulesPageRevamp and WORKFLOWS → WorkspaceWorkflowsPageRevamp directly (WorkspaceSplitNavigator.tsx), and the legacy pages no longer render their revamp counterparts. That leaves PolicyRulesPage.tsx and WorkspaceWorkflowsPage.tsx unreachable in production — they're now only referenced by tests:

• tests/ui/AgentsPromoBannersTest.tsx → PolicyRulesPage
• tests/ui/WorkspaceWorkflowsPayerRowTest.tsx and tests/ui/WorkspaceWorkflowsLoadMoreTest.tsx → WorkspaceWorkflowsPage

So those suites now validate components users can't reach, which will drift and give false confidence. Consider deleting the legacy pages and repointing (or removing) those tests as part of this PR, or confirm it's intentionally deferred to a follow-up. (Renaming the …Revamp files/props now that there's no non-revamp variant is cosmetic and fine to leave for later.)

Screenshots

Revamped Rules page and Workflows page rendering by default (no beta):

Revamped Rules page (General tab) rendering by default after beta removal

Workflows page rendering after beta removal

_{🤖 Generated by MelvinBot · web smoke test on dev NewDot · console-log inspection isn't available via the web agent-device, so "no console errors" reflects the absence of any crash/error-boundary, not a raw console read.}

[MelvinBot]

Regression hunt — remove rulesRevamp beta

No regressions found. This is a faithful beta removal: every isRulesRevampEnabled ? A : B collapses to the beta‑ON branch A, every &&/|| guard simplifies to its equivalent, and the deleted !isRulesRevampEnabled blocks had revamp replacements that stay reachable. Static audit + typecheck + a web smoke test are all clean. One intended behavior shift to QA (below), not a code defect.

What I checked ✅

• All boolean simplifications are logically equivalent to substituting isRulesRevampEnabled = true — verified hunk by hunk, including the trickier ones (RulesBillableDefaultPage !isRevamp || (…) → (…), WorkspaceTagsPage !(isRevamp && isMultiLevelTags) → !isMultiLevelTags, CategorySettingsPage's two categoryRulesEnabled blocks).
• shouldBeBlocked prop changes are safe. The pages that dropped the prop entirely (FlagForReviewRulePageBase, RequireFieldsRulePageBase, MerchantTypeRulePageBase, RulesNewPage, RulesRequireFieldsPage, RulesRequireReceiptsPage, PolicyRulesPageRevamp) each had only shouldBeBlocked={!isRulesRevampEnabled} before → false under beta‑on → undefined now (both falsy). The ones that kept !canWriteRules correctly preserved that guard. No access guard was accidentally dropped.
• No orphaned or undefined symbols. Every removed import/local (titleKey, getItemIcon, legacyFormContent, formatRequiredFieldsTitle, formatRequireReceiptsOverText, setPolicyRequiresTag, toggleBillableExpenses, setPolicyProhibitedExpense, etc.) has zero remaining references; every retained import (TranslationPaths, IconAsset, Switch, isBetaEnabled for other betas) is still used. tsc --noEmit reports no errors in the changed areas.
• No stale callers. arePolicyRulesEnabled / canPolicyAccessFeature / isPolicyFeatureEnabled dropped their isRulesRevampEnabled param; no caller in src or tests still passes it (would be a TS error).
• Export/navigator rewire is correct. WorkspaceWorkflowsPageRevamp reads policy from props, so wrapping its export in withPolicy is required, and the navigator renders it directly (no double‑wrap). PolicyRulesPageRevamp reads policy via usePolicy, so it correctly stays unwrapped.
• Moved functionality stays reachable. The requiresTag / trackBillable toggles deleted from WorkspaceTagsSettingsPage live in the revamp on RulesRequireFieldsPage / RulesBillableDefaultPage, gated on ARE_RULES_ENABLED with accessVariants=[ADMIN, PAID] — which Collect admins now satisfy. Same for the category "Settings" secondary action (now reached by tapping a category row).
• Web smoke test: the revamped Rules and Workflows pages render by default; Collect‑plan gated tabs show the Upgrade panel rather than crashing.

The one behavior shift to QA (intended, not a bug) ⚠️

Six untouched call sites already called arePolicyRulesEnabled(policy, policyCategories) with no beta arg, so they used to compute false for Collect and now compute the real value: ViolationsUtils.ts:772, ModifiedExpenseMessage.ts:545, SplitExpenseEditPage.tsx:151, MoneyRequestConfirmationList.tsx:378, useGettingStartedItems.ts:282, DynamicWorkspaceExpensifyCardDetailsPage.tsx:163. This is exactly the PR's intent (Collect graduates to Rules), but it means existing Collect workspaces that already have areRulesEnabled/category rules in Onyx will now surface rule violations and category description requirements. Worth a QA pass to confirm the backend treats Collect rules the same way the client now does — the client change is correct regardless, but this is where a product/backend mismatch would show up first.

Note

I could not execute the jest suite in this environment, so the above rests on static analysis + typecheck + the web smoke test rather than a local test run — CI's Jest job still covers the four updated test files.

_{🤖 Generated by MelvinBot · analysis + adversarial static audit at 3b1bbfd.}

[Krishna2323]

@MelvinBot review

[MelvinBot]

Review — remove rulesRevamp beta (re-review at 506fcdf)

🔴 Blocking: this PR currently fails typecheck. The merge from main / conflict-resolution commit (506fcdf) pulled in three files that still reference CONST.BETAS.RULES_REVAMP, but this PR deleted that beta from the enum. npm run typecheck fails with three TS2339: Property 'RULES_REVAMP' does not exist errors:

• src/components/Tables/WorkspaceTagsTable/index.tsx:82
• src/pages/workspace/categories/DynamicWorkspaceCategoriesSettingsPage.tsx:48 (also used at lines 87, 126, 155)
• src/pages/workspace/tags/DynamicWorkspaceViewTagsPage.tsx:81 (also used at lines 362, 428)

These are the dynamic-navigation siblings of pages this PR already collapsed (CategorySettingsPage, WorkspaceTagsPage), and they're reachable in the new workspace nav — so beyond the compile break, even if they compiled they'd fall back to isRulesRevampEnabled === false at runtime (isBetaEnabled(undefined) → false) and render the pre-revamp rows the PR is meant to remove (e.g. the tag detail "Required" toggle, the category "Requires category" toggle). This directly contradicts test steps 11–13.

Fix: collapse the beta in these three files to the beta-ON path, exactly as done for their non-dynamic counterparts — remove isRulesRevampEnabled, delete the !isRulesRevampEnabled legacy blocks, and simplify WorkspaceTagsTable's shouldShowRequiredColumn (its !isBetaEnabled(RULES_REVAMP) term becomes false, so the Required column drops out).

tsc output

src/components/Tables/WorkspaceTagsTable/index.tsx(82,106): error TS2339: Property 'RULES_REVAMP' does not exist on type '{ readonly ALL: "all"; ... }'.
src/pages/workspace/categories/DynamicWorkspaceCategoriesSettingsPage.tsx(48,60): error TS2339: Property 'RULES_REVAMP' does not exist on type '{ readonly ALL: "all"; ... }'.
src/pages/workspace/tags/DynamicWorkspaceViewTagsPage.tsx(81,60): error TS2339: Property 'RULES_REVAMP' does not exist on type '{ readonly ALL: "all"; ... }'.

What's good ✅

• The new approval-tab deep-link fix (e87f940) is correct: DynamicExpensifyCardLimitTypePage and LimitTypeStep now pass CONST.TAB.WORKFLOWS.APPROVALS into WORKSPACE_WORKFLOWS.getRoute, and the revamp page reads route.params?.tab (WorkspaceWorkflowsPageRevamp.tsx:111), so the link lands on the Approvals tab.
• The beta collapse across the originally-changed files remains clean — no leftover RULES_REVAMP refs within the PR's own diff.

Still worth addressing (from the earlier review, unchanged)

• The legacy PolicyRulesPage.tsx and WorkspaceWorkflowsPage.tsx are now unreachable in production (navigator points straight at the …Revamp pages) but are still exercised only by tests/ui/AgentsPromoBannersTest.tsx, WorkspaceWorkflowsPayerRowTest.tsx, and WorkspaceWorkflowsLoadMoreTest.tsx. Consider deleting them + repointing those tests here, or confirm it's a deliberate follow-up.

Testing note

I attempted a fresh web smoke test at 506fcdf, but the prestarted browser session was stuck on a blank page (0 accessibility nodes) for the whole drive despite the dev server building cleanly — an infra/session issue, not a product observation, so I couldn't visually confirm the runtime fallback on the two dynamic pages. The typecheck failure above is verified directly via npm run typecheck.

---

Next Steps: fix the three RULES_REVAMP references, then reply @MelvinBot review to re-check.

_{🤖 Generated by MelvinBot · re-review at 506fcdf after the merge from main.}

---

view run

[Krishna2323]

@JmillsExpensify @JS00001 @dubielzyk-expensify found an issue while testing this:

Issue: We can currently enable Require tags from Rules even when the workspace has no tags. Enabling Tags only enables the tags page with an empty tag list, so this leaves us with an invalid state where every expense gets a tag violation.

Proposed fix: Don't enable Tags from the Rules page.

1. If Tags is off, the modal sends the admin to More features to enable it.
2. If Tags is on but empty, keep Require tags disabled with a tooltip: "You don't have any tags. Please create a tag."
3. Once a tag exists, the toggle becomes available and the admin can enable it.

This avoids writing an impossible "require tags" state and removes the need for hidden state/cleanup.

Things to confirm:

• Keep the current one-tap flow when tags already exist, or always send to More features?
• Should Categories follow the same pattern?

Monosnap.screencast.2026-08-19.22-12-42.mp4

[luacmartins]

LGTM

[JmillsExpensify]

Let's trigger the upgrade path, though we can also do that later and merge what we have for now.

[Krishna2323]

@JmillsExpensify @situchan updated to upgrade path, resolving conflicts...

Monosnap.screencast.2026-09-11.00-38-34.mp4

[situchan]

All good. Holding PR is now merged

[github-actions]

🚧 JS00001 has triggered a test Expensify/App build. You can view the workflow run here.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #98662.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-4005793-817d6ea-59a34858b69ad2aee5ed5e39229ff4303938eec5/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-4005793-817d6ea-aa13ac5177d2271fa1d8d54bdbd8b00fc5268d88/index.html

Web 🕸️
https://98662.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[OSBotify]

🚀 Deployed to staging by https://github.com/JS00001 in version: 9.4.77-0 🚀

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

[MelvinBot]

Yes — help site changes are required, and I've opened a draft PR for them: #101010

Removing the rulesRevamp beta makes the revamped Rules and Workflows pages the default for every workspace and deletes the pre-revamp screens. Ten articles under docs/articles still described the old layouts.

What's stale and how the docs PR fixes it

Product change in this PR	Docs updated
Rules is now tabbed: General, Card restrictions, Expense defaults, Field requirements, Flag for review, Agents	Workspace-Rules.md rewritten around the tabs and the shipped General tab row labels
Rules is no longer Control-only — canPolicyAccessFeature now allows Collect too, but only Require fields for all expenses and Billable expenses work there	Workspace-Rules.md plan wording corrected (it said "Control plan only")
Workflows is now tabbed: Submissions, Approvals, Payments, Advanced; report rules live on Advanced	Workspace-Workflows.md, Add-Approvals.md
Category page dropped Default tax rate, Flag amounts over, Require receipts over, Require itemized receipts over, Require fields — now rules created from Category rules	Create-expense-categories.md, Workspace-Rules.md
Require categories / Require tags toggles removed from Categories > Settings and Tags > Settings — now the Require fields for all expenses rule	Require-tags-and-categories-for-expenses.md
Default spend categories (MCC) removed from Categories > Settings — now Merchant type is rules on Expense defaults	Require-tags-and-categories-for-expenses.md, Create-expense-categories.md
Merchant section → Expense defaults tab; Spend section → Card restrictions tab	Workspace-Merchant-Rules.md, Import-Merchant-Rules.md, Expensify-Card-Spend-Rules.md
Prohibited Expenses section → Flag receipt line items on General	Prohibited-Expense-Rule.md
Cash expense default → Cash expenses	Split-Expenses.md

One note worth confirming: the tab is labelled Field requirements in en.ts and in the running app, not "Require fields" as the test steps here describe it. I documented Field requirements.

Every feature name, tab name, section name, and button label in the docs PR was verified against the live UI built from this branch (48a5628) and cross-checked against src/languages/en.ts. The rewritten articles follow docs/HELP_AUTHORING_GUIDELINES.md, docs/HELPSITE_NAMING_CONVENTIONS.md, and docs/TEMPLATE.md. npm run createDocsRoutes produced no diff and npm run spell-changed passed with 0 issues.

@Krishna2323, please review the linked help site PR and confirm it reflects the current behavior. Then mark the linked help site PR Ready for review

---

view run · no recording available

[jponikarchuk]

Deploy Blocker #101018 was identified to be related to this PR.