# Manage passes at scale with Wallet Pass Campaigns
A **Wallet Pass Campaign** is a single pass design that issues many individual Apple Wallet passes and keeps some of their fields in sync from one place. Mark a field **Shared**, and your next edit reaches every pass the campaign issued. Mark it **Personal**, and each issued pass keeps its own value, such as a seat number or a loyalty balance.
## What you can do with Wallet Pass Campaigns
* Design one pass and issue it to any number of users, instead of creating passes one by one in the [pass builder](/product/messaging-channels/apple-wallet-passes/pass-builder/).
* Choose which fields update everywhere (shared) and which stay per pass (personal).
* See how many issued passes a field edit affects before you save it.
* Override a shared field on one pass, then hand control back to the campaign later.
* Attach passes issued outside a campaign, via the API, so they start following its shared fields.
* Track campaign revisions and the delivery status of each update.
## Prerequisites
Wallet Pass Campaigns use the same setup as a standalone pass: an active Apple Developer Program membership, iOS connected to the application, and the application's pass signing certificate uploaded to Pushwoosh. See [Prerequisites](/product/messaging-channels/apple-wallet-passes/#prerequisites) for the one-time setup.
## Create a campaign
1. In the Control Panel, go to **Campaigns → Wallet Passes**, then select **Campaigns** next to **All passes**.
2. Click **Create campaign**.
3. Under **Campaign**, set a **Name** and an optional **Description** for your own reference. Neither appears on the pass.
4. Under **Pass Style**, pick one of the five Apple Wallet pass styles. See [Choose a pass style](/product/messaging-channels/apple-wallet-passes/pass-builder/#choose-a-pass-style) for what each style controls.
The rest of the campaign design uses the same sections as a regular pass: **Basic Information**, **Colors**, **Pass Fields**, **Barcode**, **Expiration & Status**, **Advanced Options**, and **Location-Based Relevance**. See [Design passes in the pass builder](/product/messaging-channels/apple-wallet-passes/pass-builder/) for what each section does.
## What the Design, Passes, and History tabs show
Opening a campaign shows three tabs:
* **Design:** the pass builder for this campaign, plus the shared and personal fields and campaign images described below.
* **Passes:** every pass the campaign issued, with search, filters, and the option to issue a new pass.
* **History:** every campaign revision and the fields it changed.
A revision counter (for example, **Revision 2**) at the top of **Design** tracks how many times the campaign was saved.
## How shared and personal fields differ
The **Shared and personal fields** section on the **Design** tab lists every pass field with its current mode:
* **Shared:** the field is driven by the campaign. Editing it and saving updates every issued pass, except passes where that field was overridden (see [Override a field on one pass](#override-a-field-on-one-pass)).
* **Personal:** the field carries its own value per pass. A campaign edit does not touch it.
A field whose value looks like a per-pass placeholder (for example, `{Seat}`) defaults to personal when you create it. Other fields default to shared.
## Save a change and see its impact
Editing a shared field and clicking **Save changes** does not update every pass silently. Pushwoosh first shows how many issued passes the change affects:
* If none of the affected passes have an override on a changed field, the dialog offers one action: update every affected pass.
* If some passes override a changed field, the dialog also lists each overridden field with how many passes hold it, and adds a second action to overwrite every affected pass, including the overridden ones. Without it, the update applies only to passes still following the campaign and leaves overridden passes as they are.
## Override a field on one pass
Editing a shared field directly on one pass, instead of on the campaign, overrides that field for the pass: it keeps the value you set, and later campaign edits to that field skip it.
On the pass, Pushwoosh marks the overridden field and shows a **Use the campaign value** button next to it. Click it to drop the override and let the campaign drive that field again.
On the campaign's **Passes** tab, the **Overrides** column lists the overridden field keys for each pass, or `—` when a pass has none. Filter the list with **With overrides** to find every pass that has at least one override, or **Behind the revision** to find passes that have not yet received the campaign's latest revision.
## Issue a pass from the campaign
1. On the campaign's **Passes** tab, click **Issue pass**.
2. Enter the recipient's Pushwoosh [User ID](/product/pushwoosh-knowledge-hub/users-userids/).
3. If the campaign has personal fields with a placeholder value (for example, `{Seat}`), enter that pass's starting value for each one. A personal field with a plain value, not a placeholder, is issued with that value and can be changed per pass afterward.
4. Click **Issue pass** to confirm.
Pushwoosh generates the pass from the campaign's current design and lists it under **USER** on the campaign's **Passes** tab and on [All passes](/product/messaging-channels/apple-wallet-passes/#view-and-manage-existing-passes).
## Attach an existing pass to a campaign
A pass created outside any campaign, or issued from a different one, can join a campaign so it starts following the campaign's shared fields.
Attaching is a call to `AttachPasses` with the list of serial numbers to attach. It takes up to 500 serials at once; a larger batch is rejected entirely, with nothing attached. Calling it again with a serial that's already attached succeeds without changing anything, so a batch that was rejected or partially applied can simply be resubmitted.
The response reports each rejected serial individually, with the reason, plus a count of how many succeeded. A rejected serial is turned down for one of these reasons:
* The pass is already in another campaign.
* The pass style doesn't match the campaign's.
* The pass is missing a field the campaign expects.
* No pass with that serial exists in the application. This also covers a mistyped serial and a pass that belongs to a different platform (for example, a Google Wallet pass attached to an Apple Wallet campaign).
## Track campaign revisions and delivery status
The **History** tab lists every revision of the campaign, in order, with the fields that changed in that revision.
The delivery status of the update that pushes a revision to issued passes shows separately, above the tabs, and only for the single most recent update still in progress: a progress indicator, with a **Retry failed** option if some passes failed and a **Cancel** option to stop the remaining passes.
* **Cancel** stops sending that update to any pass it hasn't reached yet. Those passes stay on their previous revision until your next change to the campaign starts a new update that covers every pass again, including these. Filter **Passes** by **Behind the revision** to find them in the meantime.
* A pass shows as **failed** when its update didn't go through after 5 attempts. **Retry failed** gives just the failed passes a fresh set of attempts; it doesn't touch passes that already updated.
Once an update is no longer the current one, for example because you saved another revision, it can no longer be retried from here.
## Delete a campaign
Deleting a campaign does not affect passes it already issued. Every value the campaign was driving is written into each issued pass at the moment of deletion, so the pass keeps showing exactly what it showed before. Future updates to that content require editing each pass individually, since the campaign that would have pushed them no longer exists.
## Campaign images
A campaign has six image slots: **Icon**, **Logo**, **Background**, **Footer**, **Strip**, and **Thumbnail**. Uploading an image stores it in the application's [media store](/product/content/media-store/); the campaign keeps a reference to it, and each pass reads the image when it's issued or updated.
Unlike a standalone pass, where images are locked after creation, replacing a campaign image reaches every pass the campaign issued.
Each image can be up to 10 MB and up to 16 megapixels. Saving a campaign with an image over 10 MB is rejected right away, naming the slot. An image over the megapixel limit passes the save but is rejected the next time Pushwoosh renders a pass with it, for example when you issue a pass from the campaign.