shared-references/campaign-create-preflight.md

# Campaign Create Preflight

Run the matching branches after resolving exactly one writable account and before proposing, confirming, or calling `create_campaign`. Reuse valid preflight results through proposal, confirmation, and create while the account and relevant requested inputs remain unchanged. Refresh the affected branch when that context changes or the shared write-safety contract requires revalidation; advancing the workflow alone does not require another lookup. A discovery result is evidence for the approved payload, not permission to choose a value by order or guess a missing value.

## Conversions

- When the approved campaign uses `bidding_type=conversions` (oCPC), call `list_conversion_event_settings` for the selected account. Request up to 500 settings and follow `after` while `has_more` is true; only after the final page, filter to standard settings. Never use a setting whose returned `event_type` is `custom`.
- If the user's requested conversion matches only a returned setting with `event_type=custom`, treat it as unavailable for campaign bidding. Do not propose, confirm, or create a campaign with it. Ask the user to choose one returned standard event/source or change the bidding objective.
- Match the user's requested event and source to exactly one returned standard setting. If multiple standard settings share the requested event, treat the source as unresolved: do not select by list order, propose, confirm, or create. Ask the user to choose between every visible `event — source` option. If zero settings remain, ask the user to choose a returned standard event/source or change the bidding objective.
- Send exactly that one returned setting id in `conversion_event_setting_ids`. Never invent, duplicate, or combine ids. For every non-conversions campaign, omit `conversion_event_setting_ids`.

## Geo targeting

- For questions about supported geographic levels or targeting capabilities, use `ads-manager-help` and its Help Center guide. Geo search resolves particular locations; it does not establish feature eligibility or provide a complete catalog.
- Use this branch for the user's stated geographic targeting or exclusion task, including geography clearly implied by that request. Context can resolve a place when the user asks to use it, such as targeting their stated service area; an incidental place in a business name, website, address, creative, or retrieved entity does not itself request targeting.
- Plan around the distinct places needed for the request and deduplicate them before calling `search_geo_locations` for the selected account. Additional requested places can require additional calls. For multi-campaign work, share matching results across targets in the same account and relevant targeting context instead of resolving the same place separately for every campaign.
- Search uses normalized text matching, not semantic interpretation of a location description. For countries, regions, markets, or cities, start with the full place name or a known country/region code. Avoid adding type labels such as “DMA” or “metro,” or parent-country/state text that is not part of the actual name. Expand an abbreviation only when its meaning is clear. Keep the intended country and geographic level for checking the results; the query has no structured country or type filter.
- For postal targeting, use the postal code or a locality/region label. A city-name query can return postal records; those records do not establish a targetable city or a complete postal list. Do not turn a regional request into postal enumeration.
- Normally use one initial query and one targeted correction per place when results suggest a specific naming or matching issue. Repeating a query or changing only punctuation, capitalization, spacing, or accents does not improve name matching. Further attempts should require new disambiguating information, not another guessed variant or a new execution batch. Stop once a suitable match is found. If more searches would guess the user's intent or expand into surrounding places, explain the uncertainty and ask a focused clarification or use documented Help guidance. An empty result does not prove the place is unsupported, and reaching the result limit does not prove complete coverage or a next page.
- Check the returned name, `country_code`, `type`, and `canonical_name` against the intended geography. Preserve inclusions, exclusions, and the requested service boundary; do not silently substitute a broader area or claim a city/market exactly implements a radius. Explain any proposed coverage approximation and obtain approval before using it. Do not create until the requested targeting is resolved and approved; never invent or accept a pasted lookup id.
- Reuse suitable matches through proposal, confirmation, and create while the account, intended place, and relevant targeting context remain unchanged. Changes to unrelated fields such as name, copy, or budget do not require another geo lookup.
- For country targeting, prefer the returned two-letter `country_code` in `targeting.locations.countries` or `targeting.excluded_locations.countries`.
- For a supported non-country location, copy the exact returned `id` verbatim into the matching `include` list and send only `{id}`. Omit `name`, `type`, `country_code`, and `region_code`; those optional fields are revalidated and are not needed.
- A search result proves that a record exists; it does not prove account eligibility, campaign-mode eligibility, or exact service-area coverage. For a product-feed campaign, send country targeting only unless live tooling explicitly proves a finer location type is allowed. Do not send a region, city, DMA, or postal lookup id merely because search returned it.
- On create, if the user has not asked to select geographic targeting or exclusions, do not call `search_geo_locations`, ask a geo follow-up, or surface geo options. Omit geo targeting fields. If no other targeting was explicitly approved, use Ads Manager's default targeting, include that default in the proposal and approval, and omit the `targeting` field.

## Platform targeting

- Use this branch only when the user explicitly asks to target iOS app, Android app, or web. Map those requests to `ios_app`, `android_app`, and `web`; ask instead of guessing when the requested platform set is ambiguous.
- Send an approved non-empty subset in `targeting.platforms.included`. On create, omit `platforms` for all platforms, and omit `targeting` too if it would otherwise be empty; never send an empty `included` list.