[$250] Future-dated card assignments are not supported in New Expensify

[m-natarajan]

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.3.89-3
Reproducible in staging?: Y (Reproduction blocked in OldDot)
Reproducible in production?: Y
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: @EmilioRojasBlanco
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. User added a direct or commercial company card feed
2. Navigate to Workspace > Company cards
3. Click on Assign
4. Choose a card holder
5. Observe the options

Expected Result:

In New Expensify, card assignments take effect immediately and there is no option to specify a future assignment date.

Actual Result:

Users should be able to schedule/future-date card assignments, similar to the functionality available in Expensify Classic.

Workaround:

Unknown

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

Recording.2914.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022060375735002661347
• Upwork Job ID: 2060375735002661347
• Last Price Increase: 2026-05-29

[MelvinBot]

Proposal

What is the root cause of that problem?

This is a missing feature in NewDot — not a bug. The assign-card wizard in src/pages/workspace/companyCards/assignCard has no step or field for choosing when the assignment takes effect, so the assignment is always immediate.

Two concrete pieces of evidence:

• TransactionStartDateStep looks like it could be the right step, but it is for picking how far back to import past transactions — its DatePicker is explicitly capped with maxDate={new Date()}, blocking future dates (TransactionStartDateStep.tsx:142).
• The ASSIGN_COMPANY_CARD API call is fired the moment the user taps Assign Card on the confirmation step (CompanyCards.ts:478), and the request body (AssignCompanyCardParams.ts) has no field for an effective/scheduled assignment date — only startDate (the transaction-import-from date).

So adding this feature requires both:

1. A new "effective date" UI in the wizard, and
2. Backend support to defer the assignment until that date.

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

This needs backend changes outside the Expensify/App repo (the ASSIGN_COMPANY_CARD command would need to accept and honor a future effective date, and a scheduler would need to perform the assignment when that date arrives). Those changes belong in an internal repository that the open-source App contributor community does not have access to.

An internal engineer should pick up the backend half. Once the backend supports scheduling, the App-side changes are roughly:

App-side UI changes (after backend support exists)

• Add a new step constant (e.g. EFFECTIVE_DATE) to CONST.COMPANY_CARD.STEP in src/CONST/index.ts:4254.
• Add a new step screen in src/pages/workspace/companyCards/assignCard — modeled on TransactionStartDateStep, but with minDate={new Date()} instead of maxDate={new Date()} (so only today or later is selectable), and an "Assign now" / "Schedule for later" toggle.
• Extend the AssignCardData Onyx type and AssignCompanyCardParams with the new field, and pass it through assignWorkspaceCompanyCard in CompanyCards.ts:404.
• Surface the chosen effective date as a row in ConfirmationStep.tsx (similar to the existing transaction-start-date row at line 189).
• Add routes/screens and translation strings.

This is purely UI plumbing — the actual scheduling behavior depends entirely on the backend accepting the new parameter.

What alternative solutions did you explore? (Optional)

None — the request is feature parity with Classic, and the only meaningful design questions ("separate step vs. inline on the confirmation page", "calendar vs. preset offsets") should be answered after the backend contract is defined.

Note on labeling

The issue is currently labeled Bug. The described behavior ("there is no option to specify a future assignment date") is missing functionality, not broken functionality — the team may want to relabel as NewFeature to match how it gets prioritized.

---

Next Steps for Contributor+ team:
To accept: This needs internal/backend work first — please escalate to an internal engineer rather than accepting via @MelvinBot implement.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

Proposal

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

When assigning a direct/commercial company card feed in New Expensify, the "Transaction start date" step lets you pick a custom date, but the date picker won't allow any date after today — so admins can't schedule a card assignment to begin on a future date the way they can in Expensify Classic.

What is the root cause of that problem?

The assign flow already collects a start date in TransactionStartDateStep, and that value is sent to the backend as startDate → the card's scrapeMinDate (the floor for transaction import). This is the exact same field Classic uses to future-date an assignment, so the backend already supports future dates.

The only thing blocking it is on the client: both the assign step and the standalone edit page render the custom-date DatePicker with maxDate={new Date()}, hard-capping the selectable date at today.

• Assign flow — TransactionStartDateStep.tsx#L129-L144
• Edit page — WorkspaceCompanyCardEditTransactionStartDatePage.tsx#L137-L151

DatePicker's own default maxDate is already CURRENT_YEAR + 100, so these two explicit overrides are the sole reason a future date can't be selected. The submit handlers only validate isRequiredFulfilled(startDate) — there is no future-date rejection — so relaxing the cap is sufficient.

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

Replace the maxDate={new Date()} override with the existing CONST.CALENDAR_PICKER.MAX_DATE (= dateAdd(new Date(), {years: 1})) in both pickers. This is symmetric with the minDate={CONST.CALENDAR_PICKER.MIN_DATE} already used right above it, and bounds future-dating to a sensible one-year window.

In src/pages/workspace/companyCards/assignCard/TransactionStartDateStep.tsx:

                                            minDate={CONST.CALENDAR_PICKER.MIN_DATE}
-                                           maxDate={new Date()}
+                                           maxDate={CONST.CALENDAR_PICKER.MAX_DATE}

In src/pages/workspace/companyCards/WorkspaceCompanyCardEditTransactionStartDatePage.tsx:

                                        minDate={CONST.CALENDAR_PICKER.MIN_DATE}
-                                       maxDate={new Date()}
+                                       maxDate={CONST.CALENDAR_PICKER.MAX_DATE}

No other change is required: the selected startDate already flows through assignWorkspaceCompanyCard / updateCardTransactionStartDate to the ASSIGN_COMPANY_CARD / UPDATE_CARD_TRANSACTION_START_DATE commands as scrapeMinDate, which Classic relies on for future-dating today.

What alternative solutions did you explore? (Optional)

• Add a brand-new "assignment effective date" field/step — rejected: it duplicates the transaction-start-date concept that already maps to scrapeMinDate and that Classic future-dates through. It adds redundant UI/state and a much larger surface for the same result.
• Drop the maxDate prop entirely (fall back to the picker default CURRENT_YEAR + 100) — rejected: a 100-year horizon is unbounded UX; MAX_DATE's one-year window is the right bound and matches other date pickers.
• Fix only the assign step, not the edit page — rejected: editing an already-assigned card's start date hits the identical cap, so users still couldn't reschedule to a future date. Both must change for consistent behavior.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-29 15:01:20 UTC.

Proposal

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

When assigning a direct or commercial company card in New Expensify (Workspace > Company cards > Assign), the assignment takes effect immediately and there is no way to schedule it for a future date. Expensify Classic lets an admin pick a future assignment date so the card becomes active on the cardholder's account on that day. New Expensify needs an equivalent "assignment date" so admins can future-date a card assignment.

(This is effectively a feature request — the issue's Expected and Actual blocks are reversed: Expected describes today's behavior and Actual describes the desired behavior.)

What is the root cause of that problem?

The assign-card flow is a set of route-based InteractiveStepWrapper screens under src/pages/workspace/companyCards/assignCard/, enumerated in CONST.COMPANY_CARD.STEP (ASSIGNEE, CARD, CARD_NAME, TRANSACTION_START_DATE, CONFIRMATION, INVITE_NEW_MEMBER). The forward path is AssigneeStep → CardSelectionStep → TransactionStartDateStep → ConfirmationStep, with CardNameStep and TransactionStartDateStep also reachable as edit steps from the confirmation screen. The confirmation screen fires the assignment via assignWorkspaceCompanyCard, which builds an AssignCompanyCardParams payload and calls WRITE_COMMANDS.ASSIGN_COMPANY_CARD.

There is no step that collects a future effective date for the assignment, and the API payload has no field to carry one. This shouldn't be confused with the existing TransactionStartDateStep, which controls the transaction import start date, not when the assignment goes live. Its copy is "Choose your import start date. We'll sync all transactions from this date onwards" (startDateDescription), and its DatePicker is capped at maxDate={new Date()}, so it explicitly forbids future dates:

App/src/pages/workspace/companyCards/assignCard/TransactionStartDateStep.tsx

Lines 140 to 144 in f3b36e6

	}}
	minDate={CONST.CALENDAR_PICKER.MIN_DATE}
	maxDate={new Date()}
	errorText={errorText}
	/>

I confirmed this in the running app: in the assign flow the date picker disables every date after today (May 30/31 and all of June are greyed out), so the existing step genuinely can't double as an assignment date.

That startDate flows into the payload as the import boundary, distinct from any assignment effective date:

App/src/libs/actions/CompanyCards.ts

Lines 414 to 427 in f3b36e6

	const {bankName, email = '', encryptedCardNumber = '', startDate = '', customCardName = ''} = data;
	const assigneeDetails = PersonalDetailsUtils.getPersonalDetailByEmail(email);
	const optimisticCardAssignedReportAction = ReportUtils.buildOptimisticCardAssignedReportAction(assigneeDetails?.accountID ?? CONST.DEFAULT_NUMBER_ID, currentUserAccountID);
	const parameters: AssignCompanyCardParams = {
	domainAccountID: domainOrWorkspaceAccountID,
	policyID: policy.id,
	bankName,
	encryptedCardNumber,
	cardName: customCardName,
	email,
	startDate,
	reportActionID: optimisticCardAssignedReportAction.reportActionID,
	};

The AssignCompanyCardParams type confirms the gap — it carries startDate (the import date), email, cardName, encryptedCardNumber, bankName, and reportActionID, but nothing for a scheduled assignment date. So the root cause is twofold: the flow has no UI to capture a future assignment date, and ASSIGN_COMPANY_CARD has no parameter to transmit it.

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

Add a dedicated assignment-date step rather than overloading the import-date step (which must keep maxDate={new Date()}):

• Add ASSIGNMENT_DATE: 'AssignmentDate' to CONST.COMPANY_CARD.STEP and an assignmentDate field on AssignCardData in src/types/onyx/AssignCard.ts.
• Add a WORKSPACE_COMPANY_CARDS_ASSIGN_CARD_ASSIGNMENT_DATE route in ROUTES.ts and a screen in SCREENS.ts, then register it in all of src/libs/Navigation/types.ts, ModalStackNavigators/index.tsx, linkingConfig/config.ts, and RELATIONS/WORKSPACE_TO_RHP.ts (these are the five places the existing date step is wired).
• Create AssignmentDateStep.tsx with minDate={new Date()} (today-or-future) that persists via setAssignCardStepAndData({cardToAssign: {assignmentDate}}).
• Surface it as an editable row on ConfirmationStep (a new editStep case plus a row next to the transaction-start-date row), defaulting to today. Keeping it as an editable confirmation row rather than a forced extra step means the common assign-now flow is unchanged and admins opt into scheduling only when they need it.
• Thread the field through the action and payload — the only change in assignWorkspaceCompanyCard is destructuring the value and adding it to parameters:

const {
  bankName,
  email = "",
  encryptedCardNumber = "",
  startDate = "",
  customCardName = "",
  assignmentDate = "",
} = data;
const parameters: AssignCompanyCardParams = {
  /* ...existing fields... */ startDate,
  assignmentDate,
  reportActionID: optimisticCardAssignedReportAction.reportActionID,
};

This is safe because every caller already passes data as a Partial<AssignCardData>, so an absent assignmentDate defaults to '' (assign now), preserving today's immediate-assignment behavior for any flow that doesn't set it.

The one backend dependency to call out: WRITE_COMMANDS.ASSIGN_COMPANY_CARD must accept the new assignmentDate param and honor scheduling server-side (Classic already supports this, so the Auth command likely needs a matching field). The exact param name should be confirmed with the backend before finalizing AssignCompanyCardParams.

What alternative solutions did you explore? (Optional)

Reusing TransactionStartDateStep by raising its maxDate was rejected: that step's import-date semantics ("sync transactions from this date onwards") are distinct from a future effective date, and allowing future import dates would break existing transaction-sync behavior. A separate field keeps the two date concepts distinct and matches how Classic presents them. (If the backend confirms Classic's "future-dated assignment" is actually the same field as the import start date, then the simpler fix — allowing future dates in the existing step — would apply instead.)

[KJ21-ENG]

Proposal

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

New Expensify's Workspace > Company cards assignment flow lets an admin choose a cardholder, card, import start date, and card name, but it does not let the admin schedule when the card assignment should become effective. Classic supports future-dated company card assignments, so admins cannot complete that workflow in New Expensify.

What is the root cause of that problem?

The New Expensify assignment flow only models a transaction import start date, not an assignment effective date.

The assign-card routes/screens include assignee, card selection, transaction start date, card name, confirmation, and invite-new-member. There is no route or screen for choosing the assignment date itself.

App/src/ROUTES.ts

Lines 2686 to 2714 in eaaffe3

	WORKSPACE_COMPANY_CARDS_ASSIGN_CARD_ASSIGNEE: {
	route: 'workspaces/:policyID/company-cards/:feed/assign-card/:cardID/assignee',
	getRoute: (params: WorkspaceCompanyCardsAssignCardParams, backTo?: string) =>
	getUrlWithBackToParam(`workspaces/${params.policyID}/company-cards/${encodeURIComponent(params.feed)}/assign-card/${encodeURIComponent(params.cardID)}/assignee`, backTo),
	},
	WORKSPACE_COMPANY_CARDS_ASSIGN_CARD_CARD_SELECTION: {
	route: 'workspaces/:policyID/company-cards/:feed/assign-card/:cardID/card-selection',
	getRoute: (params: WorkspaceCompanyCardsAssignCardParams) =>
	`workspaces/${params.policyID}/company-cards/${encodeURIComponent(params.feed)}/assign-card/${encodeURIComponent(params.cardID)}/card-selection` as const,
	},
	WORKSPACE_COMPANY_CARDS_ASSIGN_CARD_TRANSACTION_START_DATE: {
	route: 'workspaces/:policyID/company-cards/:feed/assign-card/:cardID/transaction-start-date',
	getRoute: (params: WorkspaceCompanyCardsAssignCardParams) =>
	`workspaces/${params.policyID}/company-cards/${encodeURIComponent(params.feed)}/assign-card/${encodeURIComponent(params.cardID)}/transaction-start-date` as const,
	},
	WORKSPACE_COMPANY_CARDS_ASSIGN_CARD_CARD_NAME: {
	route: 'workspaces/:policyID/company-cards/:feed/assign-card/:cardID/card-name',
	getRoute: (params: WorkspaceCompanyCardsAssignCardParams) =>
	`workspaces/${params.policyID}/company-cards/${encodeURIComponent(params.feed)}/assign-card/${encodeURIComponent(params.cardID)}/card-name` as const,
	},
	WORKSPACE_COMPANY_CARDS_ASSIGN_CARD_CONFIRMATION: {
	route: 'workspaces/:policyID/company-cards/:feed/assign-card/:cardID/confirmation',
	getRoute: (params: WorkspaceCompanyCardsAssignCardParams, backTo?: string) =>
	getUrlWithBackToParam(`workspaces/${params.policyID}/company-cards/${encodeURIComponent(params.feed)}/assign-card/${encodeURIComponent(params.cardID)}/confirmation`, backTo),
	},
	WORKSPACE_COMPANY_CARDS_ASSIGN_CARD_INVITE_NEW_MEMBER: {
	route: 'workspaces/:policyID/company-cards/:feed/assign-card/:cardID/invite-new-member',
	getRoute: (params: WorkspaceCompanyCardsAssignCardParams) =>
	`workspaces/${params.policyID}/company-cards/${encodeURIComponent(params.feed)}/assign-card/${encodeURIComponent(params.cardID)}/invite-new-member` as const,

The existing date step is specifically transaction-import state. It uses copy like "Choose your import start date", writes dateOption and startDate into cardToAssign, and clamps the picker with maxDate={new Date()}, so a future date is intentionally not selectable there.

App/src/pages/workspace/companyCards/assignCard/TransactionStartDateStep.tsx

Lines 54 to 68 in eaaffe3

	const submit = () => {
	if (dateOptionSelected === CONST.COMPANY_CARD.TRANSACTION_START_DATE_OPTIONS.CUSTOM && !isRequiredFulfilled(startDate)) {
	setErrorText(translate('common.error.fieldRequired'));
	return;
	}
	setAssignCardStepAndData({
	cardToAssign: {
	dateOption: dateOptionSelected,
	startDate: dateOptionSelected === CONST.COMPANY_CARD.TRANSACTION_START_DATE_OPTIONS.FROM_BEGINNING ? '' : startDate,
	},
	isEditing: false,
	});
	Navigation.goBack();

App/src/pages/workspace/companyCards/assignCard/TransactionStartDateStep.tsx

Lines 127 to 144 in eaaffe3

	dateOptionSelected === CONST.COMPANY_CARD.TRANSACTION_START_DATE_OPTIONS.CUSTOM ? (
	<View style={[styles.ph5]}>
	<DatePicker
	inputID=""
	value={startDate}
	label={translate('iou.startDate')}
	onInputChange={(value) => {
	if (!isRequiredFulfilled(value)) {
	setErrorText(translate('common.error.fieldRequired'));
	} else {
	setErrorText('');
	}
	setLocalStartDate(value);
	}}
	minDate={CONST.CALENDAR_PICKER.MIN_DATE}
	maxDate={new Date()}
	errorText={errorText}
	/>

The submit path then serializes only that import startDate into the AssignCard API command. AssignCompanyCardParams has no separate field for an assignment effective date, and the confirmation copy says transactions will begin importing immediately.

App/src/libs/actions/CompanyCards.ts

Lines 402 to 425 in eaaffe3

	function assignWorkspaceCompanyCard(
	policy: OnyxEntry<Policy>,
	domainOrWorkspaceAccountID: number,
	translate: LocaleContextProps['translate'],
	data: Partial<AssignCardData>,
	currentUserAccountID: number,
	) {
	if (!policy?.id) {
	return;
	}
	const {bankName, email = '', encryptedCardNumber = '', startDate = '', customCardName = ''} = data;
	const assigneeDetails = PersonalDetailsUtils.getPersonalDetailByEmail(email);
	const optimisticCardAssignedReportAction = ReportUtils.buildOptimisticCardAssignedReportAction(assigneeDetails?.accountID ?? CONST.DEFAULT_NUMBER_ID, currentUserAccountID);
	const parameters: AssignCompanyCardParams = {
	domainAccountID: domainOrWorkspaceAccountID,
	policyID: policy.id,
	bankName,
	encryptedCardNumber,
	cardName: customCardName,
	email,
	startDate,
	reportActionID: optimisticCardAssignedReportAction.reportActionID,
	};

App/src/libs/API/parameters/AssignCompanyCardParams.ts

Lines 3 to 12 in eaaffe3

	type AssignCompanyCardParams = {
	domainAccountID?: number;
	policyID: string;
	bankName: CardFeedWithNumber | undefined;
	cardName: string;
	encryptedCardNumber: string;
	email: string;
	startDate: string;
	reportActionID: string;
	};

App/src/languages/en.ts

Lines 5377 to 5384 in eaaffe3

	chooseTransactionStartDate: 'Choose a transaction start date',
	startDateDescription: "Choose your import start date. We'll sync all transactions from this date onwards.",
	editStartDateDescription: "Choose a new transaction start date. We'll sync all transactions from that date onwards, excluding those we already imported.",
	fromTheBeginning: 'From the beginning',
	customStartDate: 'Custom start date',
	customCloseDate: 'Custom close date',
	letsDoubleCheck: "Let's double check that everything looks right.",
	confirmationDescription: "We'll begin importing transactions immediately.",

So the missing support is not that the existing date picker rejects future dates by accident. The current date picker is for transaction import history; NewDot needs an additional assignment effective-date field and API payload wiring.

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

1. Add an assignment effective-date field to the assign-card model and API params.

   • Add something like assignmentDate / effectiveDate to AssignCardData and AssignCompanyCardParams once the backend command's expected parameter name is confirmed.
   • Default it to today's date for the current immediate-assignment behavior.
   • Preserve the existing startDate field as the transaction import start date.

2. Add a dedicated "Assignment date" step to the company card assignment flow.

   • Add a new CONST.COMPANY_CARD.STEP, route, screen, linking config, and modal navigator entry.
   • Use a DatePicker with minDate={new Date()} and no "past-only" max date, because this is the future-effective assignment date.
   • Make the default value today, and allow selecting future calendar dates.
   • Keep the existing TransactionStartDateStep unchanged semantically, including its past/today-only picker and import-start-date copy.

3. Wire navigation so the normal assignment path captures both dates before confirmation.

   • After card selection, navigate through the assignment-date step and then the transaction-start-date step, or place assignment date near the confirmation edit list if product wants fewer steps for immediate assignments.
   • For the one-employee shortcut in useAssignCard, initialize assignmentDate to today before going to confirmation so the current shortcut still works.
   • When editing from confirmation, add a separate confirmation row for "Assignment date" that opens the assignment-date step. Do not reuse the "Transaction start date" row for this.

4. Pass the selected assignment date through assignWorkspaceCompanyCard() into WRITE_COMMANDS.ASSIGN_COMPANY_CARD.

   • Include the new field in optimistic assignment state only as needed for UI feedback.
   • Keep startDate mapped to transaction import start date so existing import behavior and scrapeMinDate handling do not regress.
   • Update the confirmation copy so future-dated assignments do not say imports begin immediately; show immediate copy only when the assignment date is today.

5. Add focused coverage.

   • Unit/UI test the assign-card flow renders both "Assignment date" and "Transaction start date".
   • Test that future assignment dates are selectable while transaction start dates still cannot be after today.
   • Test assignWorkspaceCompanyCard() sends both the assignment effective date and the existing transaction import startDate.
   • Add a regression test for the one-member shortcut/default path to keep immediate assignment as today's date.

What alternative solutions did you explore? (Optional)

One tempting fix is to remove maxDate={new Date()} from TransactionStartDateStep, but that would conflate two different concepts. A future transaction import start date would not necessarily mean "assign this card later", and it would also weaken the existing scrape/import-date behavior for already posted transactions.

Another option is to overload the existing startDate API field for future assignments. I would avoid that unless the backend explicitly confirms that AssignCard.startDate is already the Classic assignment effective date. In this codebase it is named, presented, edited, and later treated as the transaction start date, so a separate effective-date field is the safer App-side boundary.

[melvin-bot]

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

[aswin-s]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

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

[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.