post-connection-data-scope-filteringlisted

# Choosing a Data-Scope Filtering Strategy Customers almost never want every record their connected system has. An HRIS customer might want only active employees in specific departments. An ATS customer might want only candidates past a certain pipeline stage. A CRM customer might want only accounts owned by their team. A ticketing customer might want only tickets from one project or above a priority threshold. Decide the filtering approach **before** a live customer forces the decision, because changing it later usually requires a re-sync. ## Prerequisites - Initial sync logic working (`sync-implement-webhooks` and/or `sync-implement-polling`) ## Before Proceeding Three pieces of information are needed before writing any filter logic. If invoked from `implementing-post-connection`, the first two were answered in Step 1 — use that context. Otherwise, gather them now: - **Categories**: Which Merge categories need filtering? (`hris`, `ats`, `crm`, `accounting`, `ticketing`) — drives which filter parameters apply. - **Existing sync logic location**: Where is the sync code (webhook handler / polling job)? Filters apply inside it. Search for files that already call `/{category}/v1/{model}` or use `modified_after`. - **Filtering strategy preference**: pre-storage (Strategy 1) or post-storage (Strategy 2) — see the two-strategies section below. The recommendation is post-storage unless storage cost is a concern. Ask the user before continuing: > "Strategy 1 (pre-storage) k