Which connector?: Facebook Ad

Additional details:

The Facebook Ads connector's lead sync (LEAD, LEAD_FIELD_DATA, LEAD_CUSTOM_DISCLAIMER_RESPONSE tables) enumerates lead-gen ads across all synced ad accounts and pulls leads per ad. If the authorizing identity lacks lead access on the Page that published any single one of those ads, the Graph API returns:

(#100) Requires pages_manage_ads or leads_retrieval permission to manage the object

…and the connector fails the entire lead table sync. One inaccessible ad blocks all lead ingestion connection-wide.

This is easy to hit in practice. Lead access is granted per-Page in Meta, while ad accounts can run ads publishing under multiple Pages over their lifetime — agency or partner Pages, regional Pages, or (as in our case) a scratch Page someone used for a long-forgotten test. We traced our failures to an archived ad from June 2025, in a campaign literally named "Test - To be Deleted," publishing under a Page our authorizing user has no role on. Archived ads are still included in enumeration, so even dead experiments block the sync indefinitely.

Why the current behavior is hard to work around

• There's no ad-level or form-level exclusion in the connector — the only scoping lever is dropping the whole ad account from the connection.
• Getting lead access on the offending Page isn't always possible (partner-owned or unpublished test Pages).
• The token/scopes can be completely correct — leads_retrieval granted, re-auth done — and the sync still fails, which makes this look like an auth problem when it isn't.

Requested improvements

1. Skip, don't fail. When the leads edge for a specific ad returns a permission error, skip that ad, log a warning naming it, and continue syncing leads from accessible ads. The connector already handles missing-permission fields this way in metadata tables (e.g., the business_* fields on ACCOUNT_HISTORY) — the same graceful-degradation pattern applied per-ad would resolve this.
2. Surface the offending object ID in the error. The current error message doesn't say which ad or form failed. Identifying ours required manually reproducing the connector's calls in the Graph API Explorer under the Fivetran app and walking the ad → creative → page chain. Even without the skip behavior, an error like "leads sync failed on ad <id> (page <id>)" would turn hours of forensics into a two-minute fix.
3. (Nice to have) Option to exclude archived/deleted-status ads from lead enumeration, since they're a common source of stale permission edge cases and their leads are usually outside the 90-day retrieval window anyway.

Reproduction sketch

1. Sync an ad account containing a lead-gen ad published under Page A and another under Page B.
2. Authorize the connection as a user with lead access on Page A only.
3. Lead table sync fails entirely with the error above; no leads from Page A's ads are ingested despite being fully accessible.

Happy to provide fbtrace IDs and connection details to support privately if useful for triage.