feat: add record limit to update records

[paustint]

Updating records without a file had no way to work on a subset of an object. Every matching record is queried into the browser before anything is submitted, so a user with 9M records could not use the tool at all.

Each object now takes an optional maximum number of records to update, which lets a large data volume be worked through a chunk at a time by pairing it with criteria that stop matching once a record is updated (e.g. Only if blank) and re-running. The limit is applied to the SOQL rather than filtering client side, so the validated impacted record count, the Download Records button and the update itself all see the identical set.

An OFFSET / skip-records option was considered but Salesforce caps it at 2,000, which makes it useless for the data volumes this is meant for.

Closes #1030

[Copilot]

Pull request overview

Adds per-object record windowing to the “Update Records Without a File” flow so large data volumes can be processed incrementally, with validation, preview/download, and the actual update operating on the same SOQL-scoped record set (closes #1030).

Changes:

• Introduces optional per-object SOQL LIMIT and OFFSET, including UI inputs and validation.
• Refactors record fetching so validation preview/download and deployment share the same query path (including mixed custom criteria handling).
• Records limit/offset in data-history entries and surfaces them in deployment status messaging and history config display.

Reviewed changes

Copilot reviewed 17 out of 17 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
libs/shared/ui-core/src/mass-update-records/useDeployRecords.ts	Plumbs limit/offset into history capture and analytics flags for submissions.
libs/shared/ui-core/src/mass-update-records/MassUpdateRecordsObjectRowLimit.tsx	New UI component for per-object limit/offset inputs with inline validation messaging.
libs/shared/ui-core/src/mass-update-records/MassUpdateRecordsObjectRow.tsx	Uses shared query path for “Download Records” preview and conditionally renders limit/offset controls.
libs/shared/ui-core/src/mass-update-records/MassUpdateRecordsDeploymentRow.tsx	Displays effective limit/offset context before processing starts.
libs/shared/ui-core/src/mass-update-records/mass-update-records.utils.tsx	Implements limit/offset normalization, query composition, and windowed querying for mixed criteria.
libs/shared/ui-core/src/mass-update-records/mass-update-records.types.tsx	Extends MetadataRow with optional limit/offset and adds a shared RecordLimitAndOffset type.
libs/shared/ui-core/src/mass-update-records/data-history-capture.ts	Captures limit/offset into data-history config for accurate historical context.
libs/shared/ui-core/src/mass-update-records/tests/MassUpdateRecordsObjectRowLimit.spec.tsx	Adds unit tests for the new limit/offset input component behavior and errors.
libs/shared/ui-core/src/mass-update-records/tests/mass-update-records.utils.spec.ts	Adds extensive tests for query composition and windowed querying semantics with limit/offset.
libs/shared/ui-core/src/index.ts	Exports the new MassUpdateRecordsObjectRowLimit component from the ui-core barrel.
libs/features/update-records/src/selection/useMassUpdateFieldItems.ts	Adds state + reducer action to store per-object limit/offset and invalidate prior validation results when changed.
libs/features/update-records/src/selection/MassUpdateRecordsSelection.tsx	Wires handleRecordLimitChange through selection-level component tree.
libs/features/update-records/src/selection/MassUpdateRecordsObjects.tsx	Threads limit/offset change handler down to per-object components.
libs/features/update-records/src/selection/MassUpdateRecordsObject.tsx	Passes row limit/offset into MassUpdateRecordsObjectRow and dispatches updates upward.
libs/features/update-records/src/deployment/MassUpdateRecordsDeployment.tsx	Passes limit/offset into deployment row rendering for user visibility.
libs/features/data-history/src/lib/data-history-page.utils.ts	Adds display fields for recordLimit/recordOffset in history config UI.
apps/docs/docs/load/update-records.mdx	Documents the new limit/offset behavior, constraints, and suggested chunking workflow.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[paustint]

Code review summary

Automated review (Claude Code). Fixes below are pushed as an amend to the PR head.

Verdict: careful, well-tested feature whose LIMIT path is correct — but OFFSET is silently truncated by Salesforce, so the validated count over-promises what actually gets updated.

⚠️ Needs a decision — verified bug

OFFSET queries return only one 2,000-record batch, but Count() validation reports the full window.

Confirmed empirically against a live org:

• SELECT Count() ... LIMIT 4500 OFFSET 10 → returns 4500
• SELECT Id ... LIMIT 4500 OFFSET 10 → returns 2000, done: true, no nextRecordsUrl

So a user who asks for 4,500 records sees "4,500 records will be updated" and gets 2,000. The unit tests mock queryAll, so they cannot catch this, and apps/docs/docs/load/update-records.mdx:16 currently documents the guarantee that this breaks.

Two options: keyset paging by Id (correct, larger change) or clamp limit+count to the batch size (honest, small). Left untouched — this is a design call.

Fixed and pushed

• MassUpdateRecordsObjectRow.tsx — wasted queries on download. "Download Records" fired ~N/450 extra Id IN (...) queries whose results were discarded. queryRecordsForRow gained a { resolveCustomCriteria } option; the download path opts out. Default preserves existing behavior for queryAndPrepareRecordsForUpdate.
• mass-update-records.utils.tsx — wrong validation message. A negative offset reported "maximum offset of 2,000". Split into its own branch with an accurate message.

(ui-core: 13 files / 186 tests pass, typecheck clean.)

Also open

• MassUpdateRecordsDeploymentRow.tsx — the validated count already accounts for offset/limit, but the three stacked lines read as successive narrowings. Copy decision.
• The docs guarantee above depends on how the OFFSET question is resolved.