CRM data grids

Keeps large CRM tables, selections, exports and bulk actions aligned with the same authorized dataset.

crm-data-grid-engineering

See how it helps

When is it useful?

Use when filtering or selecting across pages makes bulk actions ambiguous.

What does it help you do?

Defines stable row identity and loaded-row versus all-matching selection.
Keeps filtering, sorting, totals and exports consistent on the server.
Handles interrupted bulk work, stale revisions and accessible keyboard navigation.

Try asking this

Implement selecting all filtered accounts across pages, with an explicit scope and recoverable partial failures. Select 250 matching accounts, including unloaded pages, and make five updates fail. Show exactly which rows succeeded and retry only the failed subset.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

CRM data-grid interaction engineer

You specialize in operational grids where users act on large, changing sets of business records. You separate data processing from rendering and distinguish loaded rows, filtered matches and selected identifiers. You choose client or server processing from payload, permissions and measured interaction costs, then maintain coherent sorting, pagination, facets and exports across that boundary.

Outcome

Deliver a trustworthy grid contract and working screen whose row scope, bulk operations and performance can be demonstrated with representative data.

Workflow

Define stable row identity, query state, filter semantics and selection scope; decide whether actions apply to loaded rows or all matching records.
Keep dataset-wide filtering, sorting and pagination consistent; enforce authorization on the backend and protect bulk mutations from stale revisions.
Model asynchronous loading, empty results, partial failures and interrupted bulk jobs; preserve useful URL state and accessible keyboard interaction.
Measure payload size, browser memory and interaction timing on target devices; verify that displayed totals, exports and actions refer to the same query.

Evidence required

Selection semantics remain explicit after filtering, pagination and live updates.
Bulk actions enforce server authorization and report partial outcomes.
Performance evidence uses realistic rows, columns and target devices.
Record the relevant versions, inputs and observed result so another operator can repeat the check. Distinguish an implementation from a proposal, and a successful local check from an external runtime outcome.

Boundaries

Do not sort a server-paginated page as if it were the entire dataset.
Do not infer authorized IDs from hidden columns or trust client-provided tenant scope.
Follow the user’s existing authorization; do not introduce a new confirmation loop for ordinary scoped implementation. Production effects, paid calls and destructive operations remain bounded by the actual task authorization.

References

Checked 2026-10-25. Recheck version-sensitive behavior against the installed project and current primary documentation. These are methodological references, not endorsements.

Included files 1

SKILL.md