[DEW in NewDot] Hide the approval workflow UI when "Hide People Table Columns" (dynamicExternalWorkflowHidePeople) is set

[MelvinBot]

Problem

When a workspace is on a Dynamic External Workflow (DEW / LINEARAPPROVAL, approvalMode === DYNAMICEXTERNAL) and the "Hide People Table Columns" option (dynamicExternalWorkflowHidePeople) is set in the DEW Manager, NewDot should hide the approval workflow UI from the customer — matching Expensify Classic (OldDot). Today NewDot ignores that flag: the Workflows page keys entirely off approvalMode === DYNAMICEXTERNAL and always renders the read-only approval workflow list plus the "custom approval workflow enabled" info banner, so the "Hide People Table Columns" toggle has no effect in NewDot.

The backend already returns dynamicExternalWorkflowHidePeople in the policy summary payload (returned only when true), so the client can decide to hide the section. NewDot just never consumes it — the App codebase currently has zero references to this flag.

Expected behavior: when dynamicExternalWorkflowHidePeople is true, keep the existing "custom approval workflow is enabled…" info banner as the explanation, but hide the actual approval workflow configuration UI so the customer never sees or reaches it.

Proposed changes

1. Add the flag to the Policy type — add dynamicExternalWorkflowHidePeople?: boolean; to src/types/onyx/Policy.ts (alongside approvalMode).

2. Gate the approval-workflow render in src/pages/workspace/workflows/WorkspaceWorkflowsPage.tsx on the flag. Suggested approach: derive something like hidePeople = !!policy?.dynamicExternalWorkflowHidePeople and, when it is true:

   • Keep the info banner — WorkspaceWorkflowsPage.tsx:711-728.
   • Skip the workflow search bar — WorkspaceWorkflowsPage.tsx:729-736.
   • Skip the displayedWorkflows.map(...) read-only workflow list — WorkspaceWorkflowsPage.tsx:742-781.
   • Skip the "add approval workflow" affordance — WorkspaceWorkflowsPage.tsx:788-799.

   Context: isDEWEnabled is computed at WorkspaceWorkflowsPage.tsx:467 via hasDynamicExternalWorkflow in src/libs/PolicyUtils.ts:1596, which today only checks approvalMode and ignores any hide flag.

3. Block deep-link access to the approvals routes while the flag is true — ensure WORKSPACE_WORKFLOWS_APPROVALS_* routes (WORKSPACE_WORKFLOWS_APPROVALS_NEW / _EDIT and WORKSPACE_WORKFLOWS_APPROVALS_EXPENSES_FROM) can't be reached via direct URL when dynamicExternalWorkflowHidePeople is true (e.g. redirect to a NotFound/full-page fallback in the approvals screens, following existing access-gating patterns in those pages).

Tests

Add a Jest test for WorkspaceWorkflowsPage covering both flag states:

• dynamicExternalWorkflowHidePeople: true → banner is rendered, workflow list / search bar / add-approval affordance are not rendered.
• flag false/absent (DEW still enabled) → existing behavior is unchanged (banner + read-only workflow list still rendered).

Open item to confirm before/while implementing

Confirm dynamicExternalWorkflowHidePeople is actually present in the NewDot policy summary payload for an affected workspace — the backend returns it only when true, so verify a real DEW workspace with the toggle set surfaces it in the client policy object.

---

This App work was split out from an internal tracking issue so an external contributor can pick it up.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022087629163120737541
• Upwork Job ID: 2087629163120737541
• Last Price Increase: 2026-08-12

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @sobitneupane (External)

[melvin-bot]

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

[vladlenskiy]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a workspace runs a Dynamic External Workflow and dynamicExternalWorkflowHidePeople is set, NewDot should stop showing the approval workflow configuration while keeping the explanatory banner.

What is the root cause of that problem?

hasDynamicExternalWorkflow answers one question, whether the policy uses DEW:

App/src/libs/PolicyUtils.ts

Line 1596 in c926b19

function hasDynamicExternalWorkflow(policy: OnyxEntry<Policy>): boolean {

WorkspaceWorkflowsPage derives isDEWEnabled from it at

App/src/pages/workspace/workflows/WorkspaceWorkflowsPage.tsx

Line 467 in c926b19

const isDEWEnabled = hasDynamicExternalWorkflow(policy);

and uses that single boolean for both the banner and the configuration below it, so "DEW is on and the people should be hidden" cannot be expressed. The approvals child screens are separately registered routes with their own fallback guards; all six include an HR read-only check and none checks this flag, so hiding the main page cannot protect a direct URL.

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

Add the field to Policy, then a predicate beside hasDynamicExternalWorkflow rather than changing it, since other features depend on its meaning:

function shouldHideDynamicExternalWorkflowPeople(policy: OnyxEntry<Policy>): boolean {
    return hasDynamicExternalWorkflow(policy) && policy?.dynamicExternalWorkflowHidePeople === true;
}

Requiring the mode too means a stale true cannot hide workflows after the mode changes. The backend sends the field only when true, so absent and false behave alike.

On the page, keep the banner at

App/src/pages/workspace/workflows/WorkspaceWorkflowsPage.tsx

Lines 711 to 727 in c926b19

	{isDEWEnabled && (
	<View style={[styles.border, shouldUseNarrowLayout ? styles.p3 : styles.p4, styles.mt6, styles.mbn3, styles.flexRow, styles.alignItemsCenter]}>
	<Icon
	src={expensifyIcons.Info}
	fill={theme.textSupporting}
	additionalStyles={styles.popoverMenuIcon}
	/>
	<View style={[styles.flex1, styles.ml3]}>
	<RenderHTML
	html={
	accountManagerReportID
	? translate('workflowsPage.customApprovalWorkflowEnabled')
	: translate('workflowsPage.customApprovalWorkflowEnabledConciergeOnly')
	}
	/>
	</View>
	</View>

and gate the five siblings after it: search bar, no-results view, workflow cards, load-more card, add affordance.

The load-more card is worth naming because it survives a partial fix. It is a sibling of displayedWorkflows.map(...), not part of it, so gating only the list still leaves "N more" on screen whenever there are more workflows than CONST.WORKFLOW_APPROVALS_INITIAL_BATCH:

App/src/pages/workspace/workflows/WorkspaceWorkflowsPage.tsx

Lines 782 to 787 in c926b19

	{hiddenWorkflowsCount > 0 && (
	<WorkflowsLoadMoreCard
	count={hiddenWorkflowsCount}
	onPress={() => setIsWorkflowListExpanded(true)}
	/>
	)}

Seven approvals routes, not three. _APPROVER, _APPROVER_CHANGE, _APPROVAL_LIMIT and _OVER_LIMIT_APPROVER have their own paths in linkingConfig/config.ts and resolve directly. _APPROVER and _APPROVER_CHANGE both mount WorkspaceWorkflowsApprovalsApproverPage, which builds its approver list from policy.employeeList with no parent screen needed, so six page components cover all seven routes.

Each already computes a shouldShowNotFoundView for FullPageNotFoundView inside AccessOrNotFoundWrapper, with isAnyHRReadOnlyWorkflowMode(policy) as the precedent, so this is one added disjunct per page:

App/src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsCreatePage.tsx

Line 54 in c926b19

const shouldShowNotFoundView = (isEmptyObject(policy) && !isLoadingReportData) || !canWriteApprovals || isPendingDeletePolicy(policy) || isAnyHRReadOnlyWorkflowMode(policy);

Import belongs in scope. Inside the More menu, which shows whenever canWriteApprovals, the Import option is excluded only by isAnyHRReadOnlyWorkflowMode, and that helper reads the Gusto, Zenefits and Merge HR connection modes only, never approvalMode. So DEW does not exclude it today, and Import mutates approval configuration.

Its three routes at

App/src/ROUTES.ts

Lines 2841 to 2852 in c926b19

	WORKSPACE_WORKFLOWS_IMPORT: {
	route: 'workspaces/:policyID/workflows/import',
	getRoute: (policyID: string) => `workspaces/${policyID}/workflows/import` as const,
	},
	WORKSPACE_WORKFLOWS_IMPORTED: {
	route: 'workspaces/:policyID/workflows/imported',
	getRoute: (policyID: string) => `workspaces/${policyID}/workflows/imported` as const,
	},
	WORKSPACE_WORKFLOWS_IMPORTED_CONFIRMATION: {
	route: 'workspaces/:policyID/workflows/imported/confirmation',
	getRoute: (policyID: string) => `workspaces/${policyID}/workflows/imported/confirmation` as const,
	},

do not share one component. _IMPORT mounts ImportWorkflowsPage, which already has shouldBeBlocked for HR read-only, so the flag slots in beside it. _IMPORTED and _IMPORTED_CONFIRMATION mount ImportedMembersPage and ImportedMembersConfirmationPage, shared with the ordinary Members import, so those need a guard conditional on route name or Members import breaks.

Download reuses the Members export command, so the file is identical to Members > Download CSV and there is no privacy argument for hiding it. Whether the More menu should disappear entirely or keep Download alone is a design call, happy either way.

One thing to confirm first: since the backend omits the field rather than sending false, how is a stored true cleared when the toggle is switched off? If policy updates merge rather than replace, the UI could stay hidden after the setting is turned off.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

• DEW with the flag true: banner present, the other five absent.
• DEW with the field omitted: unchanged.
• Not DEW with a stale true: unchanged. This is the case that justifies requiring both.
• Direct-link fallback for all seven approvals routes, with _APPROVER and _APPROVER_CHANGE as separate cases.
• The three import routes, plus that ordinary Members import still works.

Negative cases should omit the field rather than set false, and the load-more case needs more than CONST.WORKFLOW_APPROVALS_INITIAL_BATCH workflows, which tests/ui/WorkspaceWorkflowsLoadMoreTest.tsx already sets up.

What alternative solutions did you explore? (Optional)

1. Make hasDynamicExternalWorkflow return false when the flag is set. Every surface inherits it, but it changes a helper other features rely on. Rejected.

2. A local expression on the page instead of a shared predicate. Fine if the page were the only consumer, but six approvals pages need the same check.

3. Guard at the navigator level so the components never mount. Departs from the pattern the six screens share and needs its own policy lookup; worth it only if a fallback is considered insufficient.