Approver row is hidden on the workspace invite confirmation page for Dynamic External Workflow policies

[melvin-bot]

Problem

On the Members > Invite member > confirmation page, admins can set the new member's approver. That row doesn't always appear for workspaces using a Dynamic External Workflow (DEW), so admins on those workspaces can't set a manager/approver at invite time — a capability they have in Classic.

Root cause

WorkspaceInviteMessageComponent.tsx#L120 gates the row on advanced only:

const shouldShowApproverRow = isControl && policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.ADVANCED && policy?.areWorkflowsEnabled;

CONST.POLICY.APPROVAL_MODE.DYNAMICEXTERNAL is a separate mode, so DEW workspaces fall through and the row is skipped. validatedApprover is also only passed to addMembersToWorkspace when shouldShowApproverRow is true, so even a drafted approver would be dropped.

Proposed fix

Include DYNAMICEXTERNAL in the check (hasDynamicExternalWorkflow() already exists in PolicyUtils):

const isSupportedApprovalMode =
    policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.ADVANCED || policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.DYNAMICEXTERNAL;
const shouldShowApproverRow = isControl && isSupportedApprovalMode && policy?.areWorkflowsEnabled;

Keep the row hidden when shouldHideDynamicExternalWorkflowPeople(policy) is true, matching #98491.

Steps to reproduce

1. Use a Control workspace with approvalMode: dynamic_external and Workflows enabled.
2. Go to Members > Invite member, select a member, and continue to the confirmation page.
3. Expected: an Approver row appears and the chosen approver is applied on invite. Actual: no Approver row.

Related

• WS - Approver row incorrectly appears or is missing based on how the workspace is upgraded #99749 — Approver row appears/missing depending on the upgrade path (advanced policies).
• [Due for payment 2026-09-15] [DEW in NewDot] Hide the approval workflow UI when "Hide People Table Columns" (dynamicExternalWorkflowHidePeople) is set #98491 — Hide approval workflow UI when dynamicExternalWorkflowHidePeople is set.

Reported in Slack.

Issue Owner

Current Issue Owner: @thesahindia

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[melvin-bot]

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

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[samranahm]

Proposal

What is the root cause of that problem?

On Members > Invite member > confirmation page, admins on a Dynamic External Workflow (DEW) workspace never see the Approver row, so they cannot set a manager at invite time like they can in Classic.

shouldShowApproverRow in WorkspaceInviteMessageComponent.tsx only passes when approvalMode equals ADVANCED:

App/src/pages/workspace/members/WorkspaceInviteMessageComponent.tsx

Line 120 in 9f9ddbd

const shouldShowApproverRow = isControl && policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.ADVANCED && policy?.areWorkflowsEnabled;

DEW workspaces use CONST.POLICY.APPROVAL_MODE.DYNAMICEXTERNAL, a distinct mode, so they fall through the equality check and the row is skipped. Because validatedApprover is only forwarded to addMembersToWorkspace when shouldShowApproverRow is true, any drafted approver would also be dropped for these workspaces.

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

In WorkspaceInviteMessageComponent.tsx, broaden the gate to accept both supported approval modes while keeping the DEW hide rule from #98491.

App/src/pages/workspace/members/WorkspaceInviteMessageComponent.tsx

Line 120 in 9f9ddbd

const shouldShowApproverRow = isControl && policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.ADVANCED && policy?.areWorkflowsEnabled;

const isSupportedApprovalMode =
    policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.ADVANCED ||
    (policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.DYNAMICEXTERNAL && !PolicyUtils.shouldHideDynamicExternalWorkflowPeople(policy));
const shouldShowApproverRow = isControl && isSupportedApprovalMode && policy?.areWorkflowsEnabled;

This lets DEW workspaces show the Approver row and, since validatedApprover is only passed when shouldShowApproverRow is true, the chosen approver now flows into addMembersToWorkspace. The shouldHideDynamicExternalWorkflowPeople guard keeps the row hidden when dynamicExternalWorkflowHidePeople is set, consistent with #98491, so we do not expose approver selection where people management is intentionally hidden.

What alternative solutions did you explore? (Optional)

Use PolicyUtils.hasDynamicExternalWorkflow(policy) instead of comparing approvalMode directly, which centralizes the DEW check but produces the same gating result.

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[github-actions]

🤖 ProposalPolice™ is tracking duplicate proposals for this issue using an OpenAI Conversation. This comment stores that Conversation's ID and can be safely ignored.

[ahmdshrif]

Proposal

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

On a Control workspace whose approval mode is a Dynamic External Workflow (DEW), the Approver row never renders on Members > Invite member > confirmation, so an admin cannot set the new member's approver at invite time. The same flag also guards the submit call, so a drafted approver would be discarded even if the row were reachable.

What is the root cause of that problem?

The row's visibility flag is an allow-list of exactly one approval mode, written before DEW existed.

1. The gate equality-tests the raw policy.approvalMode field against a single literal — WorkspaceInviteMessageComponent.tsx#L120-L121:

const shouldShowApproverRow = isControl && policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.ADVANCED && policy?.areWorkflowsEnabled;

2. Substituting the reported setup (Control + DYNAMIC_EXTERNAL + Workflows on): isControl → true; approvalMode === 'ADVANCED' → false; areWorkflowsEnabled → true. Exactly one term fails, and DYNAMICEXTERNAL is a sibling value of ADVANCED in the same enum (CONST/index.ts#L4305-L4312).

3. The same flag is reused at submit — #L204 passes shouldShowApproverRow ? validatedApprover : undefined. With undefined, Member.ts#L1010 omits submitsTo from the API params entirely, while the optimistic employee at Member.ts#L888 still gets one. One flag, both symptoms — the row is missing and the approver would not be applied.

4. DEW is an approver-bearing mode elsewhere in the product: WorkflowsApprovalsTab.tsx#L233-L239 already lists ADVANCED and DYNAMICEXTERNAL when showing non-default workflows. The invite page is the one surface that never got the second mode — it has no DEW handling at all.

5. Not a regression: git log -S 'shouldShowApproverRow' on the file returns only the feature commit 4833f9e5def (#79878), its revert 22c9a58b893, and the re-land 64f6cc9c701. No commit ever removed DEW — the mode list was written without it, so there is no deliberate exclusion to preserve.

Every affected path — all four entry points render this same component and share the single L121 flag:

• Members > Invite member — DynamicWorkspaceInviteMessagePage.tsx#L28 (the reported repro)
• Workflows > Approvals > Expenses from > add member — the /expenses-from variant of the same component, #L90; a DEW admin hits the bug from the Workflows UI itself.
• Expensify Card > Issue new card > Invite new member — InviteNewMemberStep.tsx#L90
• Company cards > Assign card > Invite new member — InviteNewMemberStep.tsx#L139

The row (#L348-L354) is not wrapped in any step or layout condition and has no index.native.tsx — one render tree, all platforms. Destination: WorkspaceInviteMessageApproverPage.tsx#L116-L121 gates only on MEMBERS write access, with no approval-mode check, so the picker already works for DEW — no change needed there.

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

One predicate, in WorkspaceInviteMessageComponent.tsx#L121, reusing two helpers that already exist:

const isApproverConfigurable =
    policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.ADVANCED ||
    (hasDynamicExternalWorkflow(policy) && !shouldHideDynamicExternalWorkflowPeople(policy));
const shouldShowApproverRow = isControl && isApproverConfigurable && policy?.areWorkflowsEnabled;

hasDynamicExternalWorkflow and shouldHideDynamicExternalWorkflowPeople are already in PolicyUtils (L1652, L1662). The hide-people term is not extra scope — it is the regression the first term would otherwise cause, since #98491 deliberately hides approval-workflow people UI on DEW workspaces with dynamicExternalWorkflowHidePeople set.

The simple one-liner is the right fix, so it is the headline. Substituting the repro into it: hasDynamicExternalWorkflow → true; shouldHideDynamicExternalWorkflowPeople → hasDEW && !!undefined → false, so the guard passes; isControl and areWorkflowsEnabled → true. The row renders, L204 forwards validatedApprover, and Member.ts#L1010 includes submitsTo — both symptoms clear with no second mechanism. What it deliberately does not fix: policies with approvalMode undefined, which the rest of the app treats as ADVANCED via getApprovalWorkflow but this line does not. That is the upgrade-path variant owned by the open #99749, so I leave the ADVANCED term untouched rather than collide with that fix.

Regression safety: one line on one screen — non-DEW modes keep identical behavior, no shared util or exported symbol changes, and showing the row cannot flip a DEW workspace to ADVANCED, since the only approvalMode: ADVANCED write (Member.ts#L1067-L1076) lives in importMembersSpreadsheet, not on the invite path.

Secondary (optional, pre-existing): WorkspaceInviteMessageApproverPage lacks the shouldHideDynamicExternalWorkflowPeople guard its sibling WorkspaceWorkflowsApprovalsApproverPage.tsx#L68 has, so a typed URL still opens the picker on a hide-people workspace. Unreachable from the UI; happy to include if wanted.

What alternative solutions did you explore? (Optional)

1. Plain || CONST.POLICY.APPROVAL_MODE.DYNAMICEXTERNAL with no hide-people guard. Leaks on the DEW + dynamicExternalWorkflowHidePeople path: it shows the Approver row on exactly the workspaces #98491 just hid the approval-workflow UI on.
2. Route the gate through getApprovalWorkflow() or isControlOnAdvancedApprovalMode(). Leaks on the undefined-approvalMode path: that helper defaults undefined → ADVANCED, so it changes behavior for upgraded workspaces and collides head-on with the fix for #99749.
3. Drop the isControl term. Leaks onto Collect/Team policies — App only ever reads DYNAMIC_EXTERNAL (it is server-configured, never written in this repo), so there is no evidence of a non-Control DEW workspace to justify widening the row.

[abbasifaizan70]

Proposal

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

On the Members > Invite member > confirmation page, an admin can tap an Approver row to assign the new member's manager/approver at invite time. That row shows up for Control workspaces on the advanced approval mode, but it never appears for Control workspaces that use a Dynamic External Workflow (DEW). As a result, admins on DEW workspaces cannot set an approver when inviting a member — a capability they have in Expensify Classic.

What is the root cause of that problem?

The approver row visibility flag shouldShowApproverRow only accepts the ADVANCED approval mode. DEW workspaces run on a different approval mode (CONST.POLICY.APPROVAL_MODE.DYNAMICEXTERNAL = 'DYNAMIC_EXTERNAL'), so the equality check is false and the row is skipped entirely.

App/src/pages/workspace/members/WorkspaceInviteMessageComponent.tsx

Lines 120 to 121 in c1eec54

	const isControl = isControlPolicy(policy);
	const shouldShowApproverRow = isControl && policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.ADVANCED && policy?.areWorkflowsEnabled;

The approval-mode constants confirm that ADVANCED and DYNAMICEXTERNAL are two distinct values, so an === ADVANCED check can never be satisfied by a DEW policy:

App/src/CONST/index.ts

Lines 4305 to 4312 in c1eec54

	APPROVAL_MODE: {
	OPTIONAL: 'OPTIONAL',
	BASIC: 'BASIC',
	ADVANCED: 'ADVANCED',
	DYNAMICEXTERNAL: 'DYNAMIC_EXTERNAL',
	SMARTREPORT: 'SMARTREPORT',
	BILLCOM: 'BILLCOM',
	},

This same flag is also used when submitting the invite — validatedApprover is only forwarded to addMembersToWorkspace when shouldShowApproverRow is true. So even if a DEW admin had somehow drafted an approver, it would be dropped on submit:

App/src/pages/workspace/members/WorkspaceInviteMessageComponent.tsx

Line 204 in c1eec54

shouldShowApproverRow ? validatedApprover : undefined,

Note that DEW already has first-class helpers in PolicyUtils (hasDynamicExternalWorkflow returns true for the DEW approval mode), and the approver destination page (WorkspaceWorkflowsApprovalsApproverPage) already handles DEW correctly — it only blocks the page with a not-found view when the workspace has "Hide People Table Columns" set (shouldHideDynamicExternalWorkflowPeople). The invite confirmation page is simply missing the equivalent DEW branch.

App/src/libs/PolicyUtils.ts

Lines 1652 to 1664 in c1eec54

	function hasDynamicExternalWorkflow(policy: OnyxEntry<Policy>): boolean {
	return policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.DYNAMICEXTERNAL;
	}
	/**
	* Checks if the approval workflow configuration must stay hidden because the workspace's Dynamic External Workflow has
	* "Hide People Table Columns" set. The backend only returns `dynamicExternalWorkflowHidePeople` when it is `true`, so an
	* absent flag means "show". The approval mode is checked too, so a stale flag can't hide workflows on a policy that no
	* longer uses a Dynamic External Workflow.
	*/
	function shouldHideDynamicExternalWorkflowPeople(policy: OnyxEntry<Policy>): boolean {
	return hasDynamicExternalWorkflow(policy) && !!policy?.dynamicExternalWorkflowHidePeople;
	}

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

Broaden the gate so the approver row is shown for both ADVANCED and DEW policies, while continuing to hide it for DEW workspaces that have hidden the people table (matching the behavior of the approver page it links to). Reuse the existing hasDynamicExternalWorkflow and shouldHideDynamicExternalWorkflowPeople helpers rather than adding new logic.

Update the import from @libs/PolicyUtils:

App/src/pages/workspace/members/WorkspaceInviteMessageComponent.tsx

Lines 28 to 37 in c1eec54

	import {
	canMemberAssignElevatedRole,
	canMemberAssignRole,
	getDefaultApprover,
	getMemberAccountIDsForWorkspace,
	goBackFromInvalidPolicy,
	isControlPolicy,
	isSubmitPolicy,
	tryNavigateToSubmitWorkspaceUpgrade,
	} from '@libs/PolicyUtils';

import {
    canMemberAssignElevatedRole,
    canMemberAssignRole,
    getDefaultApprover,
    getMemberAccountIDsForWorkspace,
    goBackFromInvalidPolicy,
    hasDynamicExternalWorkflow,
    isControlPolicy,
    isSubmitPolicy,
    shouldHideDynamicExternalWorkflowPeople,
    tryNavigateToSubmitWorkspaceUpgrade,
} from '@libs/PolicyUtils';

Then update the visibility flag:

App/src/pages/workspace/members/WorkspaceInviteMessageComponent.tsx

Line 121 in c1eec54

const shouldShowApproverRow = isControl && policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.ADVANCED && policy?.areWorkflowsEnabled;

const isSupportedApprovalMode = policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.ADVANCED || hasDynamicExternalWorkflow(policy);
const shouldShowApproverRow = isControl && isSupportedApprovalMode && policy?.areWorkflowsEnabled && !shouldHideDynamicExternalWorkflowPeople(policy);

Because validatedApprover is already forwarded through shouldShowApproverRow (line 204), no change is needed there — once the row is shown for DEW, the drafted approver will also be applied on invite. shouldHideDynamicExternalWorkflowPeople is always false for non-DEW policies, so the added guard does not change existing advanced-mode behavior.

[neerajbachani]

🚨 Edited by proposal-police: This proposal was edited at 2026-09-09 21:31:40 UTC.

Proposal

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

On the Members → Invite member → confirmation page, admins on Control workspaces with Dynamic External Workflow (DEW) enabled cannot see or set an Approver for the member they are inviting. That capability exists in Classic and already works on Control workspaces using Advanced approval mode, so DEW admins are missing parity at invite time.

What is the root cause of that problem?

The Approver row and the invite API payload are both gated by a single shouldShowApproverRow flag in WorkspaceInviteMessageComponent. That flag only treats ADVANCED as a supported approval mode, so DEW workspaces (approvalMode: dynamic_external) never qualify even when workflows are enabled.

App/src/pages/workspace/members/WorkspaceInviteMessageComponent.tsx

Lines 119 to 120 in a6f8c39

	const isControl = isControlPolicy(policy);
	const shouldShowApproverRow = isControl && policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.ADVANCED && policy?.areWorkflowsEnabled;

DEW is a distinct approval mode. PolicyUtils.hasDynamicExternalWorkflow explicitly checks for it:

App/src/libs/PolicyUtils.ts

Lines 1607 to 1608 in a6f8c39

	function hasDynamicExternalWorkflow(policy: OnyxEntry<Policy>): boolean {
	return policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.DYNAMICEXTERNAL;

Because shouldShowApproverRow is false for DEW, two things break downstream:

1. UI — the Approver MenuItemWithTopDescription is never rendered:

App/src/pages/workspace/members/WorkspaceInviteMessageComponent.tsx

Lines 338 to 351 in a6f8c39

	{!!shouldShowApproverRow && (
	<MenuItemWithTopDescription
	title={temporaryGetDisplayNameOrDefault({
	passedPersonalDetails: approverDetails,
	defaultValue: workspaceInviteApproverDraft,
	shouldFallbackToHidden: false,
	translate,
	formatPhoneNumber,
	})}
	description={translate('workflowsPage.approver')}
	shouldShowRightIcon
	onPress={navigateToApproverPage}
	/>
	)}

2. Data — validatedApprover is only forwarded to addMembersToWorkspace when the row would have been shown, so even a drafted approver is dropped on submit:

App/src/pages/workspace/members/WorkspaceInviteMessageComponent.tsx

Lines 189 to 204 in a6f8c39

	addMembersToWorkspace(
	invitedEmailsToAccountIDsDraft ?? {},
	getPersonalDetailsOnyxDataForOptimisticUsers(newLogins, newAccountIDs, formatPhoneNumber),
	`${welcomeNoteSubject}\n\n${welcomeNote}`,
	policy,
	policyMemberAccountIDs,
	workspaceInviteRoleDraft,
	{
	accountID: currentUserPersonalDetails?.accountID,
	displayName: currentUserPersonalDetails?.displayName,
	email: currentUserPersonalDetails.email,
	avatar: currentUserPersonalDetails?.avatar,
	},
	filteredReportActions,
	shouldShowApproverRow ? validatedApprover : undefined,
	);

addMembersToWorkspace already supports passing the approver as submitsTo in the API payload — no backend change is needed; the value is simply never supplied for DEW today.

This is not platform-specific (same JS condition on web, iOS, and Android). It does not reproduce when: the workspace is not Control, workflows are disabled, approval mode is BASIC, or DEW has dynamicExternalWorkflowHidePeople set (people management is intentionally hidden per #98491). It does reproduce for any Control + DEW + areWorkflowsEnabled workspace without the hide-people flag.

The behavior dates to when the Approver row was added (#79878): shouldShowApproverRow was written with only ADVANCED in mind and DEW was never included.

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

Broaden shouldShowApproverRow so DEW is its own independent term, and keep the hide-people rule from #98491 as an outer guard — matching Classic, which does not let you set a manager on invite when the people table is hidden (trjExpensify).

shouldHideDynamicExternalWorkflowPeople already encodes that rule (hasDynamicExternalWorkflow(policy) && !!policy?.dynamicExternalWorkflowHidePeople):

App/src/libs/PolicyUtils.ts

Lines 1662 to 1664 in fe288f3

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

1. WorkspaceInviteMessageComponent.tsx — import the two helpers and replace the gate:

const isDEWPolicy = hasDynamicExternalWorkflow(policy);
const shouldShowApproverRow =
    isControl &&
    !!policy?.areWorkflowsEnabled &&
    !shouldHideDynamicExternalWorkflowPeople(policy) &&
    (isDEWPolicy || policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.ADVANCED);

Line 204 needs no edit — it inherits the widened flag, and addMembersToWorkspace already serializes the approver as submitsTo. That path does not flip approvalMode to ADVANCED; the optimistic merge MelvinBot flagged lives only in importPolicyMembers, so inviting with submitsTo will not convert a DEW workspace off its external workflow client-side.

App/src/libs/actions/Policy/Member.ts

Lines 1010 to 1011 in fe288f3

	const params: AddMembersToWorkspaceParams = {
	employees: JSON.stringify(logins.map((login) => ({email: login, role: effectiveRole, ...(approverEmail ? {submitsTo: approverEmail} : {})}))),

App/src/libs/actions/Policy/Member.ts

Lines 1067 to 1075 in fe288f3

	const shouldUpdateApprovalMode = members.some((member) => !!member.submitsTo || !!member.forwardsTo || !!member.overLimitForwardsTo || !!member.approvalLimit) && isControlPolicy(policy);
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.POLICY>> = [];
	if (shouldUpdateApprovalMode) {
	successData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
	value: {
	approvalMode: CONST.POLICY.APPROVAL_MODE.ADVANCED,

DEW has to stay an independent term. Open PR #100327 (for #99749) deletes this exact line and replaces it with shouldShowApproverRow = isAdvanceApproval && !!policy?.areWorkflowsEnabled, where isAdvanceApproval is only true when filteredApprovalWorkflows.length > 1 || approvers.length > 1 || hasOverLimitApprover. A DEW workspace on the default approver derives one workflow with one approver, so isAdvanceApproval is false and a fix that only ORs DEW into === ADVANCED disappears on rebase. Putting hide-people as an outer term (it already returns false for non-DEW) means only the ADVANCED term gets swapped for isAdvanceApproval if that PR lands first.

2. WorkspaceInviteMessageApproverPage.tsx — the sub-route has no approval-mode guard today, so a hide-people DEW workspace can still reach the picker by URL. Give it the same hide-people not-found as its twin on the Workflows tab (HR read-only is a separate pre-existing gap, not this bug):

App/src/pages/workspace/WorkspaceInviteMessageApproverPage.tsx

Lines 122 to 130 in fe288f3

	<ApproverSelectionList
	testID="WorkspaceInviteMessageApproverPage"
	headerTitle={translate('workflowsPage.approver')}
	policy={policy}
	isLoadingReportData={isLoadingReportData}
	onBackButtonPress={goBack}
	allApprovers={allApprovers}
	onSelectApprover={handleOnSelectApprover}
	shouldRequirePolicyAdmin={false}

shouldShowNotFoundView={shouldHideDynamicExternalWorkflowPeople(policy)}

Why this is the best fix:

• Root cause, not symptom — fixes the single gate that controls both UI visibility and API data, and closes the URL hole on the picker.
• Covers all paths — confirmation-page rendering, approver selection, and addMembersToWorkspace all flow through shouldShowApproverRow.
• Matches Classic + existing NewDot patterns — same shouldHideDynamicExternalWorkflowPeople helper already used on workflow approval pages.
• Rebase-safe against Derive the invite Approver row from the real approval workflows #100327 — DEW is not inferred from workflow shape.
• Minimal blast radius — two files. Advanced-mode workspaces are unchanged. Submit/Collect stay excluded via isControl.
• No timing/race concerns — purely derived from Onyx policy data already loaded on the page.

What alternative solutions did you explore? (Optional)

1. Inline approvalMode === DYNAMICEXTERNAL check — equivalent to using hasDynamicExternalWorkflow, but the helper centralizes the mode check and is already the convention elsewhere in the codebase.
2. Separate UI and submit guards — e.g. always pass validatedApprover even when the row is hidden. Rejected because it would send approver data in scenarios where [Due for payment 2026-09-15] [DEW in NewDot] Hide the approval workflow UI when "Hide People Table Columns" (dynamicExternalWorkflowHidePeople) is set #98491 / Classic intentionally hide people management, and it duplicates logic instead of fixing the shared gate.
3. OR DEW into === ADVANCED only (previous version of this proposal) — rejected because PR Derive the invite Approver row from the real approval workflows #100327 replaces that comparison with isAdvanceApproval, which is false for a default-approver DEW workspace. DEW must stay its own term.
4. Also guard the invite page with isAnyHRReadOnlyWorkflowMode — Gusto/Zenefits/Merge-managed workspaces already show an editable Approver row while the workflows approver page returns not-found. Pre-existing and unrelated to DEW; better as its own issue.

What specific scenarios should we cover in automated tests?

• Assert the Approver row is visible on the invite confirmation page for a Control workspace with approvalMode: DYNAMICEXTERNAL, areWorkflowsEnabled: true, and no dynamicExternalWorkflowHidePeople flag.
• Assert the Approver row is hidden for the same DEW workspace when dynamicExternalWorkflowHidePeople: true ([Due for payment 2026-09-15] [DEW in NewDot] Hide the approval workflow UI when "Hide People Table Columns" (dynamicExternalWorkflowHidePeople) is set #98491 / Classic parity).
• Assert the Approver row remains visible for Control + ADVANCED + workflows enabled (no regression).
• Assert addMembersToWorkspace receives validatedApprover (mapped to submitsTo in the API params) when inviting on a DEW workspace with a valid approver selected.
• Assert WorkspaceInviteMessageApproverPage shows the not-found view when dynamicExternalWorkflowHidePeople: true.

What changed vs your posted version:

• Gate now treats DEW as its own term, with hide-people as an outer guard (trjExpensify / Classic parity).
• Added why a naive === ADVANCED || DEW fix dies on rebase of #100327.
• Corrected MelvinBot: the approvalMode: ADVANCED merge is in importPolicyMembers, not addMembersToWorkspace.

[wildan-m]

Proposal

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

On the Members > Invite member flow, the confirmation page shows an Approver row so admins can assign the invited member's approver before sending the invite. For Control workspaces whose approval mode is a Dynamic External Workflow (DEW), that row never appears, so admins cannot set a manager/approver at invite time even though Workflows are enabled — a capability they have in Classic.

What is the root cause of that problem?

The Approver row is gated on the advanced approval mode only:

App/src/pages/workspace/members/WorkspaceInviteMessageComponent.tsx

Line 121 in 3607634

const shouldShowApproverRow = isControl && policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.ADVANCED && policy?.areWorkflowsEnabled;

DYNAMIC_EXTERNAL is a distinct value of policy.approvalMode (CONST.POLICY.APPROVAL_MODE.DYNAMICEXTERNAL), so on DEW workspaces shouldShowApproverRow evaluates to false and the row is never rendered.

The same flag also controls what gets submitted — when it is false, the approver argument passed to addMembersToWorkspace is forced to undefined:

App/src/pages/workspace/members/WorkspaceInviteMessageComponent.tsx

Line 204 in 3607634

shouldShowApproverRow ? validatedApprover : undefined,

So even if an approver draft exists in Onyx, it is dropped at submit time on DEW policies.

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

In WorkspaceInviteMessageComponent, widen the shouldShowApproverRow condition so it accepts the Dynamic External Workflow approval mode in addition to advanced. The existing hasDynamicExternalWorkflow helper in PolicyUtils already encodes the mode check:

App/src/libs/PolicyUtils.ts

Lines 1652 to 1654 in 3607634

	function hasDynamicExternalWorkflow(policy: OnyxEntry<Policy>): boolean {
	return policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.DYNAMICEXTERNAL;
	}

The condition becomes: show the row when the policy is Control, Workflows are enabled, and the approval mode is either advanced or dynamic external — except when shouldHideDynamicExternalWorkflowPeople returns true, meaning the workspace's DEW is configured to hide people-table workflow settings. In that case the row must stay hidden, consistent with how the rest of the approval-workflow UI treats that flag:

App/src/libs/PolicyUtils.ts

Lines 1662 to 1664 in 3607634

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

No other change is needed: the row render and the approver forwarded to addMembersToWorkspace are both keyed on the same shouldShowApproverRow flag, so once the flag is true for DEW policies, the validated approver flows through to the invite call automatically.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/100728-invite-approver-dew?expand=1

What alternative solutions did you explore? (Optional)

Comparing policy?.approvalMode against CONST.POLICY.APPROVAL_MODE.DYNAMICEXTERNAL inline instead of reusing the PolicyUtils helpers. Reusing hasDynamicExternalWorkflow and shouldHideDynamicExternalWorkflowPeople keeps the DEW semantics (including the hide-people flag handling) in one place, so the helper-based approach is preferred.

[wildan-m]

Proposal updated — added compare branch with implementation.