[$250] [Exploratory] Agents - "Add Agent" leads to "It´s not here" page when clicked after creating first agent.

[applause-bot]

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: 9.4.5-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92286
Email or phone of affected tester (no customers): applausetester+ib0005@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Workspace Settings

Action Performed:

Prerequisite: Use an expensifail account.
Prerequisite 2: Account has a workspace with "Approvals" enabled.
Prerequisite 3: No agents created yet.

1. Open the staging.new.expensify.com website.
2. Navigate to "Workspaces" > Workspace > "Workflows"
3. Scroll down to "Approvals"
4. Click on "Add Agent" > "Create Agent" > "Save"
5. Click on "Add Agent" again.
6. Note that you are redirected to a "It´s not here" page.

Expected Result:

User should be able to create a second agent via "Add Agent" button on workflows page.

Actual Result:

After creating first agent via "Add Agent" button on "Approvals", clicking on it again redirects to a "It´s not here" page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7177505_1781145213926.Agent_Approvals_3.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7177505

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022078175129129610425
• Upwork Job ID: 2078175129129610425
• Last Price Increase: 2026-07-17

Issue Owner

Current Issue Owner: @nabi-ebrahimi

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/6e1a3e60b12f099ce6bae97f30e927f21eac62a4d0803e6b94fdd74450adf324

[MelvinBot]

Issue Analysis

TL;DR: This is a stale navigation bug in the "Add agent" → Approvals workflow flow. The code that caused it has since been substantially refactored, and the specific broken navigation no longer exists on current main (v9.4.36-1). This most likely no longer reproduces — it should be re-verified on current staging before any code work.

Historical root cause (as of the reported build, v9.4.5-0): After you created your first agent from the Approvals "Add agent" button, the workflow card's first approver briefly had a blank email during the optimistic-save window (the agent row is written to Onyx before CREATE_AGENT responds). The second "Add agent" click derived its navigation target from that blank email and pushed the Approvals Edit screen with an empty firstApproverEmail. That screen resolves the workflow by matching firstApproverEmail, finds none, and renders the FullPageNotFoundView — the "It´s not here" page.

Why it looks resolved now: On current main, AddAgentPage simply calls createAgent(...) then Navigation.goBack() — it no longer navigates into the Approvals Edit screen with a seeded (possibly-empty) approver email. The dedicated hooks that produced the broken navigation (useAddAgentToApprovalWorkflow, useDeferredAgentWorkflowReconciliation) have been removed, and every remaining caller of the Edit route passes a real, user-selected approver email rather than the optimistic seed.

Investigation details & evidence

• Reported build: v9.4.5-0 (2026-06-11). Current main: v9.4.36-1 (SHA e4ae3a2). The agent-approver feature has been heavily reworked in between.
• The NotFound trigger is the !currentApprovalWorkflow branch of the Edit page's not-found guard: with an empty firstApproverEmail, no workflow matches approvers[0].email, so currentApprovalWorkflow is undefined.
• Current main no longer contains the buggy hooks or an "Add agent" card handler that reads the overlaid (blank-email) workflow. Stale comments referencing the "Add agent" seed flow remain in WorkspaceWorkflowsApprovalsApproverPage.tsx / ApprovalWorkflowEditor.tsx, but the code path that navigated to the Edit screen with an empty email is gone.
• Alternative I couldn't fully rule out without runtime testing: the "Add agent" entry point may now surface through a different UI path (e.g. the approver selection list) whose empty-state handling I couldn't exercise here. That's exactly why a quick re-test on current staging is the right next step.

Recommended next step: Re-run the exact repro on current staging (Workspace → Workflows → Approvals → Add agent → Create Agent → Save → Add agent again). If it no longer lands on the "It´s not here" page, this can be closed as resolved by the refactor. If it does still reproduce, capture the URL you land on (specifically whether the firstApproverEmail path segment is empty) so the residual entry point can be pinned down.

Possibly related agent bugs from the same feature area: #93262 (RHP → "It´s not here" after deleting an agent offline), #93266 (previous approver still shown after adding agent).

⚠️ Confidence: Medium. The code evidence strongly indicates the reported path was refactored away, but I could not run staging to confirm the bug no longer reproduces.

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis, or re-verify on staging per above.

[melvin-bot]

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

[wildan-m]

Proposal

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

On a workspace with Approvals enabled, after creating the first agent through Workflows > Approvals > "Add Agent" > "Create Agent" > "Save", clicking "Add Agent" a second time navigates to the "Hmm... it's not here" not-found page instead of opening the approver edit screen so a second agent can be added.

What is the root cause of that problem?

When an agent is created from the Workflows page while the CREATE_AGENT request is still in flight, the just-saved workflow is stashed as a deferred save and overlaid back onto the workflows list. During that overlay the workflow's approvers[0] becomes the pending agent, whose email is an empty placeholder until the server resolves the real identity. To keep routing stable through this transient state, each workflow is given a separate routingFirstApproverEmail field that always holds the original (pre-overlay) first-approver email.

This overlay and the stable routing key are produced here:

App/src/hooks/useDeferredAgentWorkflowReconciliation.ts

Lines 39 to 65 in 21ae026

	const approvalWorkflows: ApprovalWorkflowWithRouting[] = (() => {
	if (!deferredAgentWorkflowSaves || isEmptyObject(deferredAgentWorkflowSaves)) {
	return rawApprovalWorkflows.map((workflow) => ({...workflow, routingFirstApproverEmail: workflow.approvers.at(0)?.email ?? ''}));
	}
	return rawApprovalWorkflows.map((workflow) => {
	const firstApproverEmail = workflow.approvers.at(0)?.email ?? '';
	if (!firstApproverEmail) {
	return {...workflow, routingFirstApproverEmail: firstApproverEmail};
	}
	const deferredEntry = deferredAgentWorkflowSaves[buildDeferredAgentWorkflowSaveKey(policyID, firstApproverEmail)];
	if (!deferredEntry) {
	return {...workflow, routingFirstApproverEmail: firstApproverEmail};
	}
	const overlaidApprovers = deferredEntry.approvalWorkflow.approvers
	.filter((approver): approver is NonNullable<typeof approver> => !!approver)
	.map((approver) =>
	addAgentErrors && approver.accountID === deferredEntry.pendingAgentAccountID && approver.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD
	? {...approver, errors: addAgentErrors}
	: approver,
	);
	return {
	...workflow,
	approvers: overlaidApprovers,
	routingFirstApproverEmail: firstApproverEmail,
	};
	});
	})();

Every navigation path on the Workflows page that has to identify a workflow uses that stable routingFirstApproverEmail — the list key, the "edit approvers" route, the raw-workflow lookup, and the clear-pending-agent action:

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

Lines 512 to 549 in 21ae026

	key={workflow.routingFirstApproverEmail}
	pendingAction={workflow.pendingAction}
	>
	<ApprovalWorkflowSection
	approvalWorkflow={workflow}
	onPress={
	shouldBlockApprovalWorkflowEditing || !canWriteApprovals
	? undefined
	: () => {
	// Discard stale onyx edits or the Edit page's resume check would surface a prior abandoned session.
	clearApprovalWorkflow();
	Navigation.navigate(ROUTES.WORKSPACE_WORKFLOWS_APPROVALS_EDIT.getRoute(route.params.policyID, workflow.routingFirstApproverEmail));
	}
	}
	onShowAllMembersPress={
	shouldBlockApprovalWorkflowEditing
	? undefined
	: () => {
	// Use the raw workflow (pre-overlay) — a deferred-agent overlay can blank approvers[0].email, breaking ExpensesFromPage's Edit-route backTo.
	const rawWorkflow = rawApprovalWorkflows.find((w) => w.approvers.at(0)?.email === workflow.routingFirstApproverEmail);
	if (!rawWorkflow) {
	return;
	}
	selectApprovalWorkflowForEdit({workflow: rawWorkflow, defaultWorkflowMembers: availableMembers, usedApproverEmails});
	Navigation.navigate(
	ROUTES.WORKSPACE_WORKFLOWS_APPROVALS_EXPENSES_FROM.getRoute(
	route.params.policyID,
	ROUTES.WORKSPACE_WORKFLOWS.getRoute(route.params.policyID),
	),
	);
	}
	}
	onAddAgentPress={() => handleAddAgentPress(workflow)}
	onDismissApproverError={(approver) => {
	if (approver.accountID === undefined) {
	return;
	}
	clearPendingAgentFromApprovalWorkflow(route.params.policyID, workflow.routingFirstApproverEmail, approver.accountID);

The "Add Agent" handler is the one path that was not migrated to the stable key. It still derives the approver email from the live (overlaid) approvers[0]:

App/src/hooks/useAddAgentToApprovalWorkflow.ts

Lines 52 to 92 in 21ae026

	return (workflow: ApprovalWorkflow) => {
	const workflowApproverEmail = workflow.approvers.at(0)?.email ?? '';
	// Prefer the first owned agent that isn't already an approver on this workflow.
	// If every owned agent is already in the workflow there's nothing to seed, so we
	// route the admin to create a new agent instead of duplicating an existing one.
	const agentToSeed = ownedAgents.find((candidate) => !workflow.approvers.some((approver) => approver.email === candidate.email));
	if (!agentToSeed) {
	Navigation.navigate(
	ROUTES.WORKSPACE_WORKFLOWS_ADD_AGENT.getRoute({
	policyID,
	workflowApproverEmail,
	}),
	);
	return;
	}
	// Ensure the agent is a workspace member before they show up as an approver. The
	// server makes this idempotent so it's safe to call even if the agent was added via
	// the API's `policyID` parameter when CREATE_AGENT was first called.
	const isAlreadyMember = !!policy?.employeeList?.[agentToSeed.email];
	if (!isAlreadyMember && policy) {
	const policyMemberAccountIDs = Object.values(getMemberAccountIDsForWorkspace(policy.employeeList, false, false));
	addMembersToWorkspace(
	{[agentToSeed.email]: agentToSeed.accountID},
	'',
	policy,
	policyMemberAccountIDs,
	CONST.POLICY.ROLE.USER,
	formatPhoneNumber,
	{
	accountID: currentUserPersonalDetails.accountID,
	displayName: currentUserPersonalDetails.displayName,
	email: currentUserPersonalDetails.login,
	avatar: currentUserPersonalDetails.avatar,
	},
	filteredReportActions,
	);
	}
	Navigation.navigate(ROUTES.WORKSPACE_WORKFLOWS_APPROVALS_EDIT.getRoute(policyID, workflowApproverEmail, agentToSeed.email));

After the first agent is created, workflow.approvers.at(0)?.email resolves to the empty placeholder of the pending agent (not the original first approver). That empty/incorrect value is then passed as firstApproverEmail when navigating to the approver edit screen.

The edit screen looks the workflow up by matching firstApproverEmail against the raw (non-overlaid) workflow's approvers[0].email, which still holds the original approver email. With the wrong value handed in, the lookup returns nothing, currentApprovalWorkflow is undefined, and shouldShowNotFoundView becomes true — rendering the not-found page:

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

Lines 130 to 158 in 21ae026

	const getApprovalWorkflowData = () => {
	if (!policy || !personalDetails) {
	return {};
	}
	const firstApprover = route.params.firstApproverEmail;
	const result = convertPolicyEmployeesToApprovalWorkflows({
	policy,
	personalDetails,
	firstApprover,
	localeCompare,
	currentUserLogin: currentUserPersonalDetails?.login,
	});
	return {
	defaultWorkflowMembers: result.availableMembers,
	usedApproverEmails: result.usedApproverEmails,
	currentApprovalWorkflow: result.approvalWorkflows.find((workflow) => workflow.approvers.at(0)?.email === firstApprover),
	};
	};
	const {currentApprovalWorkflow, defaultWorkflowMembers, usedApproverEmails} = getApprovalWorkflowData();
	const shouldShowNotFoundView =
	(isEmptyObject(policy) && !isLoadingReportData) ||
	!canEditWorkspaceSettings(policy) ||
	isPendingDeletePolicy(policy) ||
	!currentApprovalWorkflow ||
	isAnyHRReadOnlyWorkflowMode(policy);

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

Make the "Add Agent" handler use the same stable routing key that every other navigation path on the Workflows page already uses, instead of reading the live overlaid approvers[0] email.

In src/hooks/useAddAgentToApprovalWorkflow.ts, change the handler so the value it sends as firstApproverEmail (the workflowApproverEmail it computes near the top of the returned handler and passes to both WORKSPACE_WORKFLOWS_ADD_AGENT and WORKSPACE_WORKFLOWS_APPROVALS_EDIT) comes from workflow.routingFirstApproverEmail rather than from workflow.approvers.at(0)?.email. Because the caller already passes the overlaid workflow object (which carries routingFirstApproverEmail), the handler's parameter type should be widened to the reconciled workflow type that includes that field (the ApprovalWorkflow & { routingFirstApproverEmail: string } shape returned by useDeferredAgentWorkflowReconciliation).

With this change, the second "Add Agent" click navigates to the approver edit screen with the original first-approver email, the lookup succeeds, and the user can add the second agent — matching the behavior of the existing Edit and clear-pending-agent paths.

What alternative solutions did you explore? (Optional)

Falling back to routingFirstApproverEmail only when approvers.at(0)?.email is empty (e.g. workflow.approvers.at(0)?.email || workflow.routingFirstApproverEmail). This works but keeps two sources of truth for the same routing decision; using routingFirstApproverEmail consistently — as the rest of the Workflows page already does — is cleaner and avoids re-introducing the same class of bug if the overlay ever changes approvers[0] to a non-empty but reordered value.