[Due for payment 2026-07-23] [$250] `Policy.connections` type marks every integration as present, risking runtime errors

[mhawryluk]

In the Policy type all connections are currently typed as required, when in reality only a subset of them is present in the actual data (only the already set up ones, basically). This creates a risk of runtime errors and forces type assertions across multiple files, mostly in tests. No actual errors have been spotted, but it's easy to introduce some without the TypeScript guardrail.

We should mark the type for Policy.connections as Partial, so that it accurately represents real data.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022074868797949240368
• Upwork Job ID: 2074868797949240368
• Last Price Increase: 2026-07-08

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

The Connections type declares all 10 integration keys (quickbooksOnline, xero, netsuite, intacct, quickbooksDesktop, certinia, rillet, gusto, zenefits, netsuiteMergeHR) as required. In real Onyx data only the integrations a workspace has actually set up are present, so the type overstates what exists.

The field itself is optional (connections?: Connections), but once connections is defined TypeScript treats every integration key as guaranteed. That mismatch forces ~28 as Connections / as Policy['connections'] casts in test fixtures that build partial objects, and it removes the guardrail that would otherwise flag an unchecked key access.

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

Make the Policy.connections field carry a partial shape without loosening the Connections type that indexed-access expressions depend on.

• Add a new type next to Connections: a Partial<Connections> alias (e.g. PolicyConnections).
• Change the field at Policy.ts:2648 from connections?: Connections to use that partial alias.
• Leave Connections itself all-required, and remove the now-unnecessary casts in the test fixtures.

Do not simply wrap the exported Connections in Partial<> or add ? to each key — see the alternatives section for why.

Why the naive approach breaks the build

There are 117 indexed-access type usages of the form Connections['xero']['config'], Connections['quickbooksOnline']['config'], Connections['netsuite']['options']... etc., concentrated in src/libs/actions/connections/* — e.g. Xero.ts:41.

If the keys of Connections become optional, Connections['xero'] becomes Connection<...> | undefined, so indexing ['config'] on it errors with TS2532/TS18048 at all ~117 sites. Isolating the partial shape to a separate alias used only by the Policy.connections field avoids this entirely.

AllConnections, ConnectionName, and AllConnectionName are unaffected either way — keyof yields the same key union whether members are optional or required.

Value consumers are already safe: all ~20 runtime access sites (e.g. PolicyUtils.ts, actions/connections/index.ts) already optional-chain the key (policy?.connections?.[NAME.QBO]?...) or iterate Object.keys(policy?.connections ?? {}), so the partial typing introduces no new value-access errors and accurately reflects what the code already assumes at runtime.

Verify with npm run typecheck after the change.

What alternative solutions did you explore? (Optional)

• type Connections = Partial<{...}> / add ? to each key — literally what the issue title suggests, but it breaks the 117 indexed-access type expressions above and would require a NonNullable<> wrapper at every one of them. Rejected as far more invasive.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/95608) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-08 14:51:23 UTC.

Proposal

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

The Connections map in the Policy type declares all 10 integrations (QBO, Xero, NetSuite, Sage Intacct, QBD, Certinia, Rillet, Gusto, Zenefits, Merge HR) as required keys, but the backend only sends the integrations a policy has actually connected. The type overstates what exists at runtime, disables the TypeScript guardrail against Cannot read properties of undefined crashes, and forces as casts in tests.

What is the root cause of that problem?

1. Connections is defined with every integration key required — no ? on any entry:
   

   App/src/types/onyx/Policy.ts

   Lines 2055 to 2086 in 8dbb015

   	/** Available integration connections */
   	type Connections = {
   	/** QuickBooks Online integration connection */
   	[CONST.POLICY.CONNECTIONS.NAME.QBO]: Connection<QBOConnectionData, QBOConnectionConfig>;
   	/** Xero integration connection */
   	[CONST.POLICY.CONNECTIONS.NAME.XERO]: Connection<XeroConnectionData, XeroConnectionConfig>;
   	/** NetSuite integration connection */
   	[CONST.POLICY.CONNECTIONS.NAME.NETSUITE]: NetSuiteConnection;
   	/** Sage Intacct integration connection */
   	[CONST.POLICY.CONNECTIONS.NAME.SAGE_INTACCT]: Connection<SageIntacctConnectionData, SageIntacctConnectionsConfig>;
   	/** QuickBooks Desktop integration connection */
   	[CONST.POLICY.CONNECTIONS.NAME.QBD]: Connection<QBDConnectionData, QBDConnectionConfig>;
   	/** Certinia integration connection */
   	[CONST.POLICY.CONNECTIONS.NAME.CERTINIA]: Connection<FinancialForceConnectionData, FinancialForceConnectionConfig>;
   	/** Rillet integration connection */
   	[CONST.POLICY.CONNECTIONS.NAME.RILLET]: Connection<RilletConnectionData, RilletConnectionsConfig>;
   	/** Gusto integration connection */
   	[CONST.POLICY.CONNECTIONS.NAME.GUSTO]: Connection<GustoConnectionData, GustoConnectionConfig>;
   	/** TriNet (Zenefits) integration connection */
   	[CONST.POLICY.CONNECTIONS.NAME.ZENEFITS]: Connection<ZenefitsConnectionData, ZenefitsConnectionConfig>;
   	/** Merge HR integration connection */
   	[CONST.POLICY.CONNECTIONS.NAME.MERGE_HR]: Connection<MergeHRConnectionData, MergeHRConnectionConfig, MergeHRConnectionLastSync>;
   	};

2. Policy.connections is optional only at the top level (connections?: Connections):
   

   App/src/types/onyx/Policy.ts

   Lines 2647 to 2648 in 8dbb015

   	/** All the integration connections attached to the policy */
   	connections?: Connections;

   
   So the moment code narrows policy.connections to truthy, the compiler asserts all 10 integration objects exist. In reality a policy has 0–1 of them, so unguarded per-integration access (policy.connections.netsuite.options) type-checks but can throw at runtime. The structural cause: the type models "every integration Expensify supports" when the field actually holds "the subset this policy connected."
3. This dates to PR #37806 (Mar 2024), which introduced the typed connections map with required keys; every integration added since was appended as another required key, widening the gap each time. The shape is an accident of accretion, not intentional design.
4. The workarounds the issue mentions are visible in-repo: tests cast single-integration literals to the full map in tests/unit/selectors/PolicyTest.ts (L88, L103, L159, ~15 more), tests/unit/Search/SearchUIUtilsTest.ts (L2386, L8261), and tests/unit/hooks/useGettingStartedItems.test.ts (L332, L356); tests/unit/TodosUtilsTest.ts L51 carries a comment complaining that "Policy['connections'] is typed as the full integration map."

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

Apply Partial at the single convergence point every consumer reads — the Policy field itself, exactly as the OP suggests:

/** All the integration connections attached to the policy */
connections?: Partial<Connections>;

(

App/src/types/onyx/Policy.ts

Lines 2647 to 2648 in 8dbb015

	/** All the integration connections attached to the policy */
	connections?: Connections;

)

I audited every consumer of policy.connections and of the Connections type; the fallout is deliberately tiny because the codebase is already runtime-defensive — the type was the only lie:

• One production signature to widen: getConnectionBankAccountsForReconciliation(connections: OnyxEntry<Connections>, ...) → OnyxEntry<Partial<Connections>> at

  App/src/libs/CardUtils.ts

  Line 491 in 8dbb015

  function getConnectionBankAccountsForReconciliation(connections: OnyxEntry<Connections>, connectionName: PolicyConnectionName | undefined): Array<{id: string; name: string}> {

  — its callers (CardReconciliationPage, TravelInvoicingContinuousReconciliationSection, NetSuiteAdvancedPage) pass policy?.connections directly, and its body already optional-chains every key, so this is type-only.
• Everything else compiles unchanged: PolicyUtils accesses use policy?.connections?.[name] throughout (e.g.

  App/src/libs/PolicyUtils.ts

  Lines 2261 to 2262 in 8dbb015

  	function getConnectedIntegration(policy: Policy | undefined, connectionNames: readonly ConnectionName[] = getAccountingConnectionNames()) {
  	return connectionNames.find((integration) => !!policy?.connections?.[integration]);

  ); HRUtils narrows via optional chains before bare access (

  App/src/libs/HRUtils.ts

  Lines 132 to 144 in 8dbb015

  	function getHRAdvancedModeFinalApprover(policy?: OnyxEntry<Policy>): string | null {
  	if (policy?.connections?.gusto?.config?.approvalMode === CONST.GUSTO.APPROVAL_MODE.MANAGER) {
  	return policy.connections.gusto.config.finalApprover ?? null;
  	}
  	if (policy?.connections?.zenefits?.config?.approvalMode === CONST.ZENEFITS.APPROVAL_MODE.MANAGER) {
  	return policy.connections.zenefits.config.finalApprover ?? null;
  	}
  	if (policy?.connections?.merge_hris?.config?.approvalMode === CONST.MERGE_HR.APPROVAL_MODE.MANAGER) {
  	return policy.connections.merge_hris.config.finalApprover ?? null;
  	}
  	return null;
  	}

  ); the Object.keys(policy?.connections ?? {}) sites (SearchUIUtils L1099, tag/category/rules pages) are key-only; the one Object.values site already guards with conn?. (

  App/src/pages/home/GettingStartedSection/hooks/useGettingStartedItems.ts

  Line 152 in 8dbb015

  isComplete: !!getValidConnectedIntegration(policy) || Object.values(policy?.connections ?? {}).some((conn) => !!conn?.lastSync?.successfulDate),

  ). ConnectionName = keyof Connections is untouched since Connections itself is unchanged.
• Test cleanup the issue asks for: drop the now-redundant as Policy['connections'] / as Connections casts in the four test files listed above (single-integration literals become directly assignable), and remove the workaround comment in TodosUtilsTest.ts.

Regression safety in one sentence: this is a compile-time-only change — no runtime value or behavior changes anywhere, and tsc/existing unit tests verify it.

Why the obvious alternative fails: the tempting edit is to add ? to each key inside Connections itself. That breaks the three generic helpers that index into the type — Partial<Connections[TConnectionName]['config']> at

App/src/libs/actions/connections/index.ts

Line 221 in 8dbb015

function updateManyPolicyConnectionConfigs<TConnectionName extends ConnectionNameExceptNetSuite, TConfigUpdate extends Partial<Connections[TConnectionName]['config']>>(

and

App/src/libs/actions/PolicyConnections.ts

Line 72 in 8dbb015

function updateConnectionConfig<TConnectionName extends ConnectionNameExceptNetSuite, TConfigUpdate extends Partial<Policy.Connections[TConnectionName]['config']>>(

, plus Connections[keyof Connections] at

App/src/libs/PolicyUtils.ts

Line 2131 in 8dbb015

connection?: Connections[keyof Connections],

— because with optional keys the indexed access resolves to Connection | undefined and ['config'] no longer compiles; each would need NonNullable<...> wrapping. Keeping Connections as the canonical complete map (the "registry" of integration shapes) and marking only the data-bearing field Partial fixes the data model without touching the generics.

What alternative solutions did you explore? (Optional)

1. Optional keys inside Connections — rejected above: breaks the generic config-update helpers and changes the meaning of the exported type (AllConnections, ConnectionName derivations) for zero extra safety over Partial at the field.
2. Leave the type and add runtime guards where missing — doesn't restore the compiler guardrail, which is the entire point of the issue; the next unguarded access ships silently.
3. A named Partial<Connections> alias at the field — functionally identical to the headline; only worth it if reviewers want the type reusable in test builders.

[yusufdeveloper2903]

Proposal

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

The connections field on the Policy type is typed so that every integration is a required property, but the backend only returns the integrations that are actually set up. So TypeScript believes connections that aren't there are always present, which hides the risk of runtime errors and forces as-casts (mostly in tests) whenever we build a policy with only a subset of connections.

What is the root cause of that problem?

The value type of connections — the Connections type — lists each integration as a required key:

App/src/types/onyx/Policy.ts

Lines 2055 to 2086 in f65848c

	/** Available integration connections */
	type Connections = {
	/** QuickBooks Online integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.QBO]: Connection<QBOConnectionData, QBOConnectionConfig>;
	/** Xero integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.XERO]: Connection<XeroConnectionData, XeroConnectionConfig>;
	/** NetSuite integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.NETSUITE]: NetSuiteConnection;
	/** Sage Intacct integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.SAGE_INTACCT]: Connection<SageIntacctConnectionData, SageIntacctConnectionsConfig>;
	/** QuickBooks Desktop integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.QBD]: Connection<QBDConnectionData, QBDConnectionConfig>;
	/** Certinia integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.CERTINIA]: Connection<FinancialForceConnectionData, FinancialForceConnectionConfig>;
	/** Rillet integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.RILLET]: Connection<RilletConnectionData, RilletConnectionsConfig>;
	/** Gusto integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.GUSTO]: Connection<GustoConnectionData, GustoConnectionConfig>;
	/** TriNet (Zenefits) integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.ZENEFITS]: Connection<ZenefitsConnectionData, ZenefitsConnectionConfig>;
	/** Merge HR integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.MERGE_HR]: Connection<MergeHRConnectionData, MergeHRConnectionConfig, MergeHRConnectionLastSync>;
	};

and the Policy type uses that type directly:

App/src/types/onyx/Policy.ts

Line 2648 in f65848c

connections?: Connections;

Because the field is Connections (not a partial), any policy.connections that isn't undefined is typed as containing all ten integrations. That produces two concrete symptoms:

1. Latent runtime-error risk. policy.connections?.[CONST.POLICY.CONNECTIONS.NAME.QBO] is typed as Connection<…> and never undefined, so code that assigns a connection to a variable and dereferences it unguarded still compiles — even though that integration may be absent at runtime. Most call sites happen to trail with ?. (e.g. ?.[QBO]?.config) and are safe by luck, but nothing in the type enforces it.
2. Forced casts. Any value that legitimately holds only a subset of connections isn't assignable to the all-required Connections, so we work around it with assertions — e.g. policy?.connections as Record<string, unknown> here:

App/src/libs/PolicyUtils.ts

Line 2435 in f65848c

return Object.values(CONST.POLICY.CONNECTIONS.UNSUPPORTED_NAMES).some((integration) => !!(policy?.connections as Record<string, unknown>)?.[integration]);

and as Policy / createMock<Connections> casts around subset mocks throughout tests/unit.

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

Mark the field's value type as partial so it matches the real data — one line:

App/src/types/onyx/Policy.ts

Line 2648 in f65848c

connections?: Connections;

connections?: Partial<Connections>;

Why scope it at the field and not on the Connections type itself: Connections is also consumed as a complete shape in indexed-access types like Connections['rillet']['config']['subsidiaryID'] and Connections[keyof Connections]:

App/src/libs/actions/connections/Rillet.ts

Line 279 in f65848c

function updateRilletSubsidiary(policyID: string, subsidiaryID: Connections['rillet']['config']['subsidiaryID'], oldSubsidiaryID?: Connections['rillet']['config']['subsidiaryID']) {

App/src/libs/PolicyUtils.ts

Line 2129 in f65848c

connection?: Connections[keyof Connections],

Adding ? to each member of Connections would make those members possibly-undefined and break every indexed-access alias. Wrapping only the field in Partial<Connections> leaves Connections, AllConnections, and keyof Connections untouched, so ConnectionName and Object.keys(policy?.connections ?? {}) as ConnectionName[] keep working unchanged:

App/src/libs/PolicyUtils.ts

Line 285 in f65848c

const connectionsToCheck = connectionNames ?? (Object.keys(policy?.connections ?? {}) as ConnectionName[]);

Fallout to clean up in the same PR (this is the point of the change — it surfaces the latent gaps):

• One production param that is fed policy.connections directly, getConnectionBankAccountsForReconciliation(connections: OnyxEntry<Connections>, …), should be loosened to OnyxEntry<Partial<Connections>> to accept the newly-partial value:

  App/src/libs/CardUtils.ts

  Line 492 in f65848c

  function getConnectionBankAccountsForReconciliation(connections: OnyxEntry<Connections>, connectionName: PolicyConnectionName | undefined): Array<{id: string; name: string}> {

• Any remaining assign-then-use site that TS newly flags gets a ?. or an early-return guard. Most already guard (e.g. the Certinia block gates on if (certiniaConnection && …)), so this is expected to be a handful of spots, not a sweep.

• The now-redundant as Record<string, unknown> / as Policy workarounds around subset connections can be dropped.

Note: functions that already accept an individual connection as optional — e.g. getIntegrationLastSuccessfulDate(connection?: Connections[keyof Connections]), which early-returns on !connection — need no change; they already model absence.

This is intentionally minimal: one type edit plus fixing the errors it legitimately exposes. It doesn't invent new state or restructure Connections; it just makes the field say what the data already is.

What alternative solutions did you explore? (Optional)

1. Add ? to every member inside the Connections type instead of wrapping the field. Rejected: it also makes Connections['rillet']['config'][…], Connections['quickbooksDesktop'][…], and Connections[keyof Connections] index a possibly-undefined member, breaking those indexed-access aliases, and it flips AllConnections too — more churn for no extra safety.
2. Hand-rolled mapped type {[K in keyof Connections]?: Connections[K]} at the field. Functionally identical to Partial<Connections> but more verbose; Partial reads better and is the idiom already used elsewhere in this file.
3. Leave the type as-is and rely on optional chaining discipline. Rejected: it's exactly the status quo the issue is about — the type gives no guardrail, so a missing ?. compiles silently, and subset mocks still need casts.

[lorretheboy]

Proposal

What is the root cause of that problem?

The Connections type declares every integration key (QBO, Xero, NetSuite, Sage Intacct, etc.) as required:

App/src/types/onyx/Policy.ts

Lines 2055 to 2086 in 8dbb015

	/** Available integration connections */
	type Connections = {
	/** QuickBooks Online integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.QBO]: Connection<QBOConnectionData, QBOConnectionConfig>;
	/** Xero integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.XERO]: Connection<XeroConnectionData, XeroConnectionConfig>;
	/** NetSuite integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.NETSUITE]: NetSuiteConnection;
	/** Sage Intacct integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.SAGE_INTACCT]: Connection<SageIntacctConnectionData, SageIntacctConnectionsConfig>;
	/** QuickBooks Desktop integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.QBD]: Connection<QBDConnectionData, QBDConnectionConfig>;
	/** Certinia integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.CERTINIA]: Connection<FinancialForceConnectionData, FinancialForceConnectionConfig>;
	/** Rillet integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.RILLET]: Connection<RilletConnectionData, RilletConnectionsConfig>;
	/** Gusto integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.GUSTO]: Connection<GustoConnectionData, GustoConnectionConfig>;
	/** TriNet (Zenefits) integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.ZENEFITS]: Connection<ZenefitsConnectionData, ZenefitsConnectionConfig>;
	/** Merge HR integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.MERGE_HR]: Connection<MergeHRConnectionData, MergeHRConnectionConfig, MergeHRConnectionLastSync>;
	};

and the policy field uses it as-is:

App/src/types/onyx/Policy.ts

Lines 2647 to 2648 in 8dbb015

	/** All the integration connections attached to the policy */
	connections?: Connections;

In reality the backend only sends entries for integrations that are actually connected, so once policy.connections exists TypeScript wrongly guarantees all ten integrations are present. That lets unguarded access like connections.netsuite.options.data compile even when the workspace never connected NetSuite (today such code only survives thanks to voluntary ?. chaining, e.g. in getConnectionBankAccountsForReconciliation), and it forces as Connections casts in test fixtures and mocks (e.g. __mocks__/reportData/connections.ts, tests/unit/WorkflowUtilsTest.ts) because a realistic single-connection object doesn't satisfy the type.

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

Change the policy field to connections?: Partial<Connections>; at the declaration linked above. Wrapping at the field (rather than making the keys of Connections optional) keeps keyof Connections and type-level lookups like Connections['rillet']['config'] (used throughout src/libs/actions/connections/) working unchanged.

Then fix the handful of places that consume a whole Connections value so they accept the partial shape, e.g. widen the parameter to OnyxEntry<Partial<Connections>> here:

App/src/libs/CardUtils.ts

Line 491 in 8dbb015

function getConnectionBankAccountsForReconciliation(connections: OnyxEntry<Connections>, connectionName: PolicyConnectionName | undefined): Array<{id: string; name: string}> {

Finally, drop the now-unnecessary as Connections assertions in tests and mocks (__mocks__/reportData/connections.ts, ReportPreviewActionUtilsTest.ts, PolicyMemberTest.ts, SearchUIUtilsTest.ts, WorkflowUtilsTest.ts), and add ?./guards anywhere npm run typecheck newly flags a possibly-undefined connection — those flags are exactly the latent runtime errors the issue is about.

What alternative solutions did you explore? (Optional)

Making each key inside Connections optional directly ([NAME.QBO]?: ...). Rejected because indexed-access types such as Connections['rillet']['config'] would resolve through | undefined and break many existing type references; Partial<> at the single usage point is a smaller, safer change.

[abbasifaizan70]

Proposal

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

The Policy.connections object's type (Connections) marks every accounting/HR integration (QBO, Xero, NetSuite, Sage Intacct, QBD, Certinia, Rillet, Gusto, Zenefits, Merge HR) as a required key. In reality, a policy only ever has the connections that have actually been set up by the user, so most of these keys are missing at runtime. Because TypeScript believes all of them are always present, code has to fall back to as Connections casts or non-null assertions to satisfy the compiler, which removes the type-safety net and risks runtime errors (e.g. accessing .config on undefined).

What is the root cause of that problem?

The Connections type defines each integration key as a mandatory property instead of an optional one, even though Policy.connections itself is optional and, when present, will realistically only contain the subset of integrations the workspace has connected.

This is the type definition where every integration key (QBO, XERO, NETSUITE, etc.) is declared without a ?, forcing TypeScript to assume all ten connections always exist together.

App/src/types/onyx/Policy.ts

Lines 2055 to 2086 in 243120a

	/** Available integration connections */
	type Connections = {
	/** QuickBooks Online integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.QBO]: Connection<QBOConnectionData, QBOConnectionConfig>;
	/** Xero integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.XERO]: Connection<XeroConnectionData, XeroConnectionConfig>;
	/** NetSuite integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.NETSUITE]: NetSuiteConnection;
	/** Sage Intacct integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.SAGE_INTACCT]: Connection<SageIntacctConnectionData, SageIntacctConnectionsConfig>;
	/** QuickBooks Desktop integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.QBD]: Connection<QBDConnectionData, QBDConnectionConfig>;
	/** Certinia integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.CERTINIA]: Connection<FinancialForceConnectionData, FinancialForceConnectionConfig>;
	/** Rillet integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.RILLET]: Connection<RilletConnectionData, RilletConnectionsConfig>;
	/** Gusto integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.GUSTO]: Connection<GustoConnectionData, GustoConnectionConfig>;
	/** TriNet (Zenefits) integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.ZENEFITS]: Connection<ZenefitsConnectionData, ZenefitsConnectionConfig>;
	/** Merge HR integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.MERGE_HR]: Connection<MergeHRConnectionData, MergeHRConnectionConfig, MergeHRConnectionLastSync>;
	};

Because Connections is fully required, consumers that only have partial connection data (very common in tests, and possible in production when a connection hasn't synced yet) are forced to bypass the type system with unsafe casts, as seen for example in tests/unit/WorkflowUtilsTest.ts, tests/unit/Search/SearchUIUtilsTest.ts, tests/actions/PolicyMemberTest.ts, and tests/actions/ReportPreviewActionUtilsTest.ts, all of which use as Connections to force-fit partial mock data into the fully-required type.

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

Make every integration key on Connections optional using Partial, so the type accurately reflects that a policy only has the connections it has actually configured. AllConnections and ConnectionName/AllConnectionName derive from Connections, so they will automatically pick up the optionality without further changes.

App/src/types/onyx/Policy.ts

Lines 2055 to 2086 in 243120a

	/** Available integration connections */
	type Connections = {
	/** QuickBooks Online integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.QBO]: Connection<QBOConnectionData, QBOConnectionConfig>;
	/** Xero integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.XERO]: Connection<XeroConnectionData, XeroConnectionConfig>;
	/** NetSuite integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.NETSUITE]: NetSuiteConnection;
	/** Sage Intacct integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.SAGE_INTACCT]: Connection<SageIntacctConnectionData, SageIntacctConnectionsConfig>;
	/** QuickBooks Desktop integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.QBD]: Connection<QBDConnectionData, QBDConnectionConfig>;
	/** Certinia integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.CERTINIA]: Connection<FinancialForceConnectionData, FinancialForceConnectionConfig>;
	/** Rillet integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.RILLET]: Connection<RilletConnectionData, RilletConnectionsConfig>;
	/** Gusto integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.GUSTO]: Connection<GustoConnectionData, GustoConnectionConfig>;
	/** TriNet (Zenefits) integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.ZENEFITS]: Connection<ZenefitsConnectionData, ZenefitsConnectionConfig>;
	/** Merge HR integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.MERGE_HR]: Connection<MergeHRConnectionData, MergeHRConnectionConfig, MergeHRConnectionLastSync>;
	};

/** Available integration connections */
type Connections = Partial<{
    /** QuickBooks Online integration connection */
    [CONST.POLICY.CONNECTIONS.NAME.QBO]: Connection<QBOConnectionData, QBOConnectionConfig>;

    /** Xero integration connection */
    [CONST.POLICY.CONNECTIONS.NAME.XERO]: Connection<XeroConnectionData, XeroConnectionConfig>;

    /** NetSuite integration connection */
    [CONST.POLICY.CONNECTIONS.NAME.NETSUITE]: NetSuiteConnection;

    /** Sage Intacct integration connection */
    [CONST.POLICY.CONNECTIONS.NAME.SAGE_INTACCT]: Connection<SageIntacctConnectionData, SageIntacctConnectionsConfig>;

    /** QuickBooks Desktop integration connection */
    [CONST.POLICY.CONNECTIONS.NAME.QBD]: Connection<QBDConnectionData, QBDConnectionConfig>;

    /** Certinia integration connection */
    [CONST.POLICY.CONNECTIONS.NAME.CERTINIA]: Connection<FinancialForceConnectionData, FinancialForceConnectionConfig>;

    /** Rillet integration connection */
    [CONST.POLICY.CONNECTIONS.NAME.RILLET]: Connection<RilletConnectionData, RilletConnectionsConfig>;

    /** Gusto integration connection */
    [CONST.POLICY.CONNECTIONS.NAME.GUSTO]: Connection<GustoConnectionData, GustoConnectionConfig>;

    /** TriNet (Zenefits) integration connection */
    [CONST.POLICY.CONNECTIONS.NAME.ZENEFITS]: Connection<ZenefitsConnectionData, ZenefitsConnectionConfig>;

    /** Merge HR integration connection */
    [CONST.POLICY.CONNECTIONS.NAME.MERGE_HR]: Connection<MergeHRConnectionData, MergeHRConnectionConfig, MergeHRConnectionLastSync>;
}>;

With Connections now correctly optional per-key, the as Connections casts in tests/unit/WorkflowUtilsTest.ts, tests/unit/Search/SearchUIUtilsTest.ts, tests/actions/PolicyMemberTest.ts, and tests/actions/ReportPreviewActionUtilsTest.ts can be removed since partial mock connection objects will satisfy the type directly. Any production call site that assumed a specific connection always exists on policy.connections will now surface a TypeScript error, which should be fixed by adding the appropriate optional-chaining/guard, ensuring the compiler actually catches the runtime risk described in this issue instead of masking it.

[dilshodmackbook-sketch]

Proposal

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

Policy.connections is typed so that every integration (QBO, Xero, NetSuite, Sage Intacct, QBD, Certinia, Rillet, Gusto, Zenefits, Merge HR) is a required key, but the backend only sends the connections that have actually been set up. TypeScript therefore treats an absent connection as guaranteed-present, which invites unguarded runtime access and forces as casts across the codebase (mostly tests).

What is the root cause of that problem?

The connections field on the policy is typed as Connections:

App/src/types/onyx/Policy.ts

Lines 2647 to 2648 in 8dbb015

	/** All the integration connections attached to the policy */
	connections?: Connections;

and Connections declares every integration as a non-optional property:

App/src/types/onyx/Policy.ts

Lines 2056 to 2086 in 8dbb015

	type Connections = {
	/** QuickBooks Online integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.QBO]: Connection<QBOConnectionData, QBOConnectionConfig>;
	/** Xero integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.XERO]: Connection<XeroConnectionData, XeroConnectionConfig>;
	/** NetSuite integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.NETSUITE]: NetSuiteConnection;
	/** Sage Intacct integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.SAGE_INTACCT]: Connection<SageIntacctConnectionData, SageIntacctConnectionsConfig>;
	/** QuickBooks Desktop integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.QBD]: Connection<QBDConnectionData, QBDConnectionConfig>;
	/** Certinia integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.CERTINIA]: Connection<FinancialForceConnectionData, FinancialForceConnectionConfig>;
	/** Rillet integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.RILLET]: Connection<RilletConnectionData, RilletConnectionsConfig>;
	/** Gusto integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.GUSTO]: Connection<GustoConnectionData, GustoConnectionConfig>;
	/** TriNet (Zenefits) integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.ZENEFITS]: Connection<ZenefitsConnectionData, ZenefitsConnectionConfig>;
	/** Merge HR integration connection */
	[CONST.POLICY.CONNECTIONS.NAME.MERGE_HR]: Connection<MergeHRConnectionData, MergeHRConnectionConfig, MergeHRConnectionLastSync>;
	};

Because the whole object is optional but its members are not, policy.connections?.[CONST.POLICY.CONNECTIONS.NAME.QBO] is inferred as a non-nullable Connection. Callers can then dereference .config / .data / .lastSync with no guard even though that connection may not exist in the real payload — a latent undefined access. The same mismatch is why building a policy with a single connection requires as Connections / as Policy['connections'] (27 such assertions live in tests/), e.g.:

App/src/libs/PolicyUtils.ts

Lines 2437 to 2441 in 8dbb015

	return Object.values(CONST.POLICY.CONNECTIONS.UNSUPPORTED_NAMES).some((integration) => !!(policy?.connections as Record<string, unknown>)?.[integration]);
	}
	function hasSupportedOnlyOnOldDotIntegration(policy: Policy | undefined) {
	return Object.values(CONST.POLICY.CONNECTIONS.SUPPORTED_ONLY_ON_OLDDOT).some((integration) => !!(policy?.connections as Record<string, unknown>)?.[integration]);

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

Wrap the field in Partial so each integration key becomes optional, matching real data:

/** All the integration connections attached to the policy */
connections?: Partial<Connections>;

I'd change only the field on Policy, not the Connections type itself, so keyof-derived helpers (ConnectionName = keyof Connections, AllConnectionName) and the AllConnections shape stay intact.

After this, policy.connections?.[name] is correctly Connection | undefined, so npm run typecheck will flag any spot that dereferences a connection without a guard — those get an optional chain / early return. The now-redundant as Connections / as Policy['connections'] assertions in the test files can be dropped, since a partial connections object satisfies the type natively.

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

This is a type-only change, so the primary regression guard is npm run typecheck — an unguarded access on a possibly-absent connection now fails compilation. On top of that I'd keep/add a unit test around the connection helpers in PolicyUtils (e.g. getConnectedIntegration) asserting they return undefined/false for a policy whose connections omits the queried integration, so the "connection may be absent" contract is exercised at runtime too.

What alternative solutions did you explore? (Optional)

• Make each member of the Connections type itself optional ([NAME.QBO]?: ...). It reaches the same result but is more invasive and risks the keyof Connections derivations (ConnectionName, AllConnectionName) that other modules rely on; Partial<Connections> on the single field is one line and leaves those derivations untouched.
• Leave the type as-is and add runtime guards / assertions where crashes appear. Rejected — it treats symptoms case by case, keeps the misleading type and the existing casts, and gives no compile-time protection against new unguarded access.

[aswin-s]

Proposal

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

In the Policy type, the connections field is typed such that every integration key is required, but at runtime only the connections that have actually been set up exist on the object. This mismatch between the type and real data risks runtime errors when code accesses a connection that isn't present, and it forces type assertions in multiple call sites (mostly tests) to work around the guardrail.

What is the root cause of that problem?

The connections property on the Policy type is declared as a fully-populated Record/object keyed by every CONST.POLICY.CONNECTIONS.NAME value, so TypeScript treats every integration (QuickBooks Online, Xero, NetSuite, Sage Intacct, QuickBooks Desktop, Workspaces, etc.) as guaranteed-present. In reality the backend only sends the connections the workspace has configured, so consumers reading policy.connections?.quickbooksOnline get a value typed as defined when it may be undefined, requiring assertions and hiding potential runtime errors.

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

1. In src/types/onyx/Policy.ts, change the connections field on Policy from a required-keys mapped/object type to a Partial<...> of that same shape (or mark each key optional) so accessing any integration yields T | undefined.
2. Keep the outer connections?: optional (policies without any integration have no field at all); the change is to the inner value type only.
3. Sweep call sites that currently rely on the non-optional typing — remove now-unnecessary as assertions (largely in tests and connection utils under src/libs/actions/connections/ and src/libs/PolicyUtils.ts) and add narrowing (if (policy.connections?.[CONST.POLICY.CONNECTIONS.NAME.QBO]) { ... }) where the code previously assumed presence.
4. Run tsc and fix the newly surfaced errors — these are exactly the latent bugs the issue is calling out; each should be resolved by a presence check rather than a new assertion.
5. Verify no assertion of the form policy.connections[...] remains for connection keys without a preceding truthiness check.

What alternative solutions did you explore? (Optional)

[samranahm]

Proposal

What is the root cause of that problem?

The Policy type declares connections as a fully-populated object where every integration key is present. In reality the backend only sends the connections that have actually been set up, so a policy with just QuickBooks Online connected has no intacct, netsuite, xero, etc. keys at all.

Because the type says every integration is always present, TypeScript never forces callers to guard against a missing connection. Helpers that read specific connections trust the type and access keys that may not exist at runtime. For example, isAnyHRConnected in HRUtils.ts delegates to per-integration checks that read into policy.connections:

App/src/libs/HRUtils.ts

Lines 81 to 83 in 8dbb015

	function isAnyHRConnected(policy?: OnyxEntry<Policy>): boolean {
	return isGustoConnected(policy) || isZenefitsConnected(policy) || isMergeHRConnected(policy);
	}

and route helpers like getConnectionNameFromRouteParam in AccountingUtils.ts map a route param straight onto a connection key that the type guarantees but the data may not include:

App/src/libs/AccountingUtils.ts

Lines 37 to 39 in 8dbb015

	function getConnectionNameFromRouteParam(routeParam: ValueOf<typeof CONST.POLICY.CONNECTIONS.ROUTE>) {
	return ROUTE_NAME_MAPPING[routeParam];
	}

The gap: the source of truth type in Policy.ts marks all integrations as required, so the compiler cannot warn about undefined connections, and contributors compensate with type assertions (mostly in tests). This creates real risk of runtime errors that TypeScript would otherwise catch.

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

1. In Policy.ts (src/types/onyx/Policy.ts), change the connections field so its value type is wrapped in Partial, which makes every integration key optional and matches the real Onyx data.

/** Integration connections that have been set up for this policy */
connections?: Partial<Connections>;

This is the single deepest change: once the type reflects that a given integration may be absent, every consumer is type-checked against undefined.

2. Resolve the new compiler errors surfaced by the stricter type at the call sites that read specific integrations, for example the per-integration helpers used by isAnyHRConnected in HRUtils.ts:

App/src/libs/HRUtils.ts

Lines 81 to 83 in 8dbb015

	function isAnyHRConnected(policy?: OnyxEntry<Policy>): boolean {
	return isGustoConnected(policy) || isZenefitsConnected(policy) || isMergeHRConnected(policy);
	}

Add optional chaining or existence guards where a connection is accessed, so a missing integration returns false or undefined instead of assuming the key exists.

3. Remove the now-unnecessary type assertions across the affected files (mostly tests) that were added only to satisfy the previously over-strict required type. With the Partial type in place these assertions are no longer needed, so the code accurately expresses that only set-up connections are present.

What alternative solutions did you explore? (Optional)

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.

[melvin-bot]

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

[melvin-bot]

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