[Submit] Automatic changes to Submit workspaces on creation add change history to #admins

[garrettmknight]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number:
Reproducible in staging?:
Reproducible in production?:
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by:
Slack conversation (hyperlinked to channel name):

Action Performed:

1. Sign up for an account
2. Add it to the Submit2026 beta
3. Switch to Classic
4. Navigate to expensify.com/pricing
5. Create a Submit workspace > rerouted to NewDot

Expected Result:

Initial settings don't trigger workspace change history in #admins

Actual Result:

Initial settings trigger workspace change history in #admins and threads, creating two unread threads it shouldn't.

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @abzokhattab

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022060029276585361598
• Upwork Job ID: 2060029276585361598
• Last Price Increase: 2026-05-28

[MelvinBot]

Proposal

What is the root cause of that problem?

When a Submit workspace is created during the EMPLOYER onboarding flow, the App sends the CreateWorkspace API command to the backend with Submit-specific default settings (workflows enabled, tags enabled, distance rates enabled, company cards disabled, ADVANCED approval mode, auto-harvesting disabled, IMMEDIATE reporting frequency). These differ from the "base" workspace defaults.

The backend processes the CreateWorkspace command and applies these settings — but it appears to use the same code path as subsequent setting changes, which generates POLICYCHANGELOG_* report actions in the #admins room. Initial configuration during workspace creation should not produce change history entries, since nothing is actually being "changed" — these are the workspace's first-ever settings.

The relevant frontend code that builds these Submit-specific defaults is in buildPolicyData. The POLICYCHANGELOG actions themselves are generated entirely by the backend — the App frontend never creates them (confirmed by zero references to POLICYCHANGELOG in any action file). The frontend only renders them via PolicyChangeLogContent.tsx.

What changes do you think we should make in order to solve the problem?

This is a backend issue. The backend's CreateWorkspace handler (and/or CompleteGuidedSetup) needs to suppress POLICYCHANGELOG report action generation when applying initial default settings during workspace creation. The fix requires changes outside the App repo — an internal engineer with access to the backend should update the workspace creation handler to treat initial settings as configuration rather than changes.

No App-side fix is appropriate here, since the frontend correctly renders whatever the backend sends.

What alternative solutions did you explore? (Optional)

An App-side workaround could filter out POLICYCHANGELOG actions that share the same timestamp as the workspace CREATED action, but this would be a hack — the correct fix is for the backend to not generate these actions in the first place.

Supporting evidence

Workspace creation entry point: useAutoCreateSubmitWorkspace.ts:47-72 — calls createWorkspace() with type: SUBMIT and engagementChoice: EMPLOYER.

Submit-specific defaults differ from standard workspaces (Policy.ts:2594-2656):

• areWorkflowsEnabled: true, areTagsEnabled: true, areDistanceRatesEnabled: true
• areCompanyCardsEnabled: false, approvalMode: ADVANCED, harvesting.enabled: false
• autoReportingFrequency: IMMEDIATE

POLICYCHANGELOG types (CONST/index.ts:1633-1736) include UPDATE_FEATURE_ENABLED, UPDATE_AUTO_REPORTING_FREQUENCY, UPDATE_REIMBURSEMENT_CHOICE, UPDATE_AUTO_HARVESTING — all matching the settings configured during Submit workspace creation.

After creation, the user is navigated to the workspace categories page with the #admins side panel open (navigateAfterOnboarding.ts), where they immediately see the spurious change history threads.

---

Next Steps for Contributor+ team:
To accept: This requires a backend fix — escalate to an internal engineer with access to the workspace creation handler.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

When a Submit workspace is created, the #admins room gets workspace-change-history actions (and two resulting unread threads) even though these settings are just the workspace's initial configuration, not edits a user made afterward.

On the App (frontend) side, workspace creation applies all the Submit defaults — approvalMode, areWorkflowsEnabled, areTagsEnabled, reimbursementChoice, areDistanceRatesEnabled, etc. — inline as a single optimistic policy write, not as separate change actions:

https://github.com/Expensify/App/blob/main/src/libs/actions/Policy/Policy.ts#L2629-L2660

The only optimistic #admins report action the frontend creates is the standard "created this workspace" action (buildOptimisticCreatedReportAction), bundled into adminsReportActionData:

https://github.com/Expensify/App/blob/main/src/libs/actions/Policy/Policy.ts#L2782-L2784

So the extra change-history entries aren't coming from the frontend. They're emitted by the backend CreateWorkspace command, which applies the Submit defaults as if they were post-creation setting changes and logs each one as a POLICYCHANGELOG action into the #admins room. That's what produces the two unread threads in the screenshot.

Because the offending actions originate server-side, this isn't fixable purely in the App repo — the backend needs to apply the initial Submit configuration as part of the workspace's creation state rather than as logged change events.

What changes do you think we should make in order to solve the problem?

The core fix belongs in the backend CreateWorkspace flow (Auth / Web-Expensify): when a Submit workspace is created, the automatic initial settings should be written as the workspace's starting configuration, not run through the policy-change-log path that posts POLICYCHANGELOG actions to #admins. Concretely, the create command should suppress change-log generation for settings that are applied as part of creation (approval mode, workflows, tags, reimbursement choice, distance rates), so no reportComment/changelog actions are appended and no threads are spawned.

Since this is Internal (API) work, I'd flag it for an Expensify engineer rather than attempt a frontend-only patch. The App side is already correct — it sends these as creation parameters, not edits — so no change is needed in buildPolicyData/createWorkspace.

If we wanted a frontend-side mitigation while the backend is fixed, we could filter POLICYCHANGELOG actions on the #admins room whose timestamp matches the workspace created time (i.e. emitted as part of creation) so they don't render or mark threads unread, but that's a fragile band-aid and I'd only pursue it if the backend fix is blocked.

What alternative solutions did you explore? (Optional)

I considered whether the frontend was pushing optimistic change-log actions for the Submit defaults, but it isn't — the settings are part of the single policy SET, and adminsReportActionData carries only the CREATED action, so there's nothing on the App side to remove. I also considered hiding the #admins room's initial actions client-side, but that masks the symptom rather than fixing the cause and risks hiding legitimate early changes, so the backend fix is the right scope.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

When a Submit workspace is created from the classic flow, initial configuration changes (like setting up default settings, categories, or policies) are being applied through the same code paths that record change history in the #admins report. These automated setup changes should be treated as "silent" initial configuration rather than user-initiated changes that deserve audit trail entries.

What changes do you think we should make in order to solve the problem?

The workspace creation action in src/libs/actions/Policy/ likely triggers policy update actions (e.g., updateWorkspaceCustomUnitAndRate, setPolicyCustomTaxName, or similar) without an announce: false / silent flag. I'd suggest adding a isInitialSetup parameter (or similar) to the relevant policy update calls made during workspace creation, and skipping the #admins report action message when that flag is set.

// In the relevant policy update action (e.g., Policy/index.ts)
- function updatePolicySetting(policyID: string, setting: PolicySetting) {
+ function updatePolicySetting(policyID: string, setting: PolicySetting, isInitialSetup = false) {
     const optimisticData = [...];
-    const reportAction = buildPolicyChangeReportAction(setting);
+    const reportAction = isInitialSetup ? null : buildPolicyChangeReportAction(setting);
     // skip adding reportAction to admins report when null
 }

Then in the workspace creation flow, pass isInitialSetup: true for all automated initial configuration calls so no change history threads are created in #admins.

What alternative solutions did you explore?

An alternative would be to batch all initial setup changes into a single API call that bypasses report action creation entirely, but that would require larger backend changes. The flag approach is simpler and more surgical.

[melvin-bot]

Current assignees @hungvu193 and @abzokhattab are eligible for the External assigner, not assigning anyone new.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022060029276585361598

[github-actions]

⚠️ @KJ21-ENG Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[github-actions]

⚠️ @yusufdeveloper2903 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).