Skip to main content

Create vs Update Behavior

When you publish campaigns, Whathead determines whether to create new entities or update existing ones based on whether nodes have platform IDs. Understanding this behavior helps you predict what will happen when you click Publish and manage campaigns effectively.
What you’ll learn:
  • When entities are created new versus updated
  • How platform IDs determine publishing behavior
  • Partial success scenarios and how to handle them
  • Retry workflows for failed campaigns
  • Cross-platform transfer publishing behavior

CREATE vs UPDATE Decision

Whathead makes a simple decision for each node: Does the node have an existing platform ID?
  • No → CREATE (send create request to platform)
  • Yes → Check for changes:
    • Has changes → UPDATE (send update request to platform)
    • No changes → SKIP (no API call)

Platform IDs Explained

Platform IDs are unique identifiers assigned by advertising platforms:
  • existingCampaignId: ID from Meta, TikTok, Snapchat, or Google for a campaign
  • existingAdSetId: ID for an ad set (or ad group/ad squad)
  • existingAdId: ID for an ad
When you load existing campaigns using Select Existing or Expand, Whathead stores these IDs on the nodes. When you publish, Whathead uses these IDs to update the existing entities rather than creating new ones.
You can see platform IDs in the node details panel. Nodes without platform IDs will always create new entities when published.

When Entities Are Created New

Entities are created new in these scenarios:

1. Canvas-Origin Nodes

When you add a node directly on the canvas using + Campaign, + Ad Set, or + Ad, the node has no platform ID. Publishing creates a new entity. Example:
You click + Campaign → Configure campaign → Publish
Result: New campaign created on platform
Canvas-origin nodes always CREATE even if you publish them multiple times. Each publish creates a new entity because the node has no platform ID to update.

2. Pasted Nodes

When you copy and paste nodes, Whathead clears platform IDs from the pasted nodes. This ensures pasted nodes create new entities rather than updating the originals. Example:
You load Campaign A → Copy and paste → Publish
Result: New Campaign B created (duplicate of Campaign A)
Copy/paste is the recommended way to duplicate campaign structures. It automatically clears IDs so you don’t accidentally update the original campaigns.

3. Duplicated Nodes

When you use the duplicate function, Whathead creates new nodes without platform IDs. Example:
You select Campaign A → Duplicate → Publish
Result: New Campaign B created (duplicate of Campaign A)

4. Reconnected Nodes

When you change a node’s parent connection (reconnect), Whathead clears the platform ID. Publishing creates a new entity under the new parent. Example:
You move Ad X from Ad Set A to Ad Set B → Publish
Result: New Ad Y created under Ad Set B (Ad X remains under Ad Set A)
Reconnecting creates duplicates rather than moving entities. Platforms don’t support moving entities between parents, so Whathead creates a new entity under the new parent instead.

5. First Publish

When you publish a campaign for the first time, all nodes create new entities because none have platform IDs yet. Example:
You build Campaign A with 2 ad sets and 4 ads → Publish
Result: 1 new campaign, 2 new ad sets, 4 new ads created on platform

When Entities Are Updated

Entities are updated in these scenarios:

1. Loaded from Platform with Changes

When you load existing campaigns using Select Existing or Expand, the nodes have platform IDs. If you make changes and publish, Whathead updates the existing entities. Example:
You load Campaign A → Change budget → Publish
Result: Campaign A updated on platform with new budget

2. Previously Published and Edited

When you publish a canvas-origin campaign, it receives a platform ID. If you edit and republish, it updates the entity you created. Example:
First publish: Campaign A created (receives platform ID)
Edit Campaign A → Publish again
Result: Campaign A updated on platform
After the first publish, canvas-origin nodes receive platform IDs and behave like loaded campaigns. Subsequent publishes update rather than create.

3. Expanded Entities with Changes

When you expand a campaign to load its ad sets and ads, those entities have platform IDs. Changes to expanded entities update the existing entities. Example:
You load Campaign A → Expand to load ad sets → Edit Ad Set 1 → Publish
Result: Ad Set 1 updated on platform

When Entities Are Skipped

Entities are skipped (no API call) in these scenarios:

1. Loaded from Platform with No Changes

When you load existing campaigns but don’t make any changes, Whathead skips them during publish. Example:
You load Campaign A → Don't change anything → Publish
Result: Campaign A skipped (no API call)
Skipping unchanged entities is efficient and normal. You’re not required to make changes to every entity when publishing.

2. Previously Published with No New Changes

When you publish a campaign, then publish again without making changes, Whathead skips all entities. Example:
First publish: Campaign A created
Publish again without changes
Result: All entities skipped

3. Partial Campaign Changes

When you change some entities in a campaign but not others, Whathead updates changed entities and skips unchanged ones. Example:
You load Campaign A with 3 ad sets → Edit Ad Set 1 only → Publish
Result: Campaign A skipped, Ad Set 1 updated, Ad Sets 2 and 3 skipped

Partial Success Scenarios

When publishing multiple campaigns or entities, some may succeed while others fail. Whathead handles partial success gracefully.

What Happens During Partial Success

1

Publishing begins

Whathead starts sending create or update requests to the platform for all entities.
2

Some succeed, some fail

Successful entities receive platform IDs and go live. Failed entities show error messages.
3

Dependent entities blocked

If a parent entity fails, its children are not published. For example, if a campaign fails, its ad sets and ads are not published.
4

Results displayed

You see success or failure status for each entity with detailed error messages for failures.

Example Partial Success Scenario

Publishing 3 campaigns:

Campaign A: SUCCESS (created)
  ├─ Ad Set A1: SUCCESS (created)
  │   └─ Ad A1a: SUCCESS (created)
  └─ Ad Set A2: SUCCESS (created)
      └─ Ad A2a: SUCCESS (created)

Campaign B: FAILED (budget below minimum)
  ├─ Ad Set B1: NOT PUBLISHED (parent failed)
  └─ Ad Set B2: NOT PUBLISHED (parent failed)

Campaign C: SUCCESS (created)
  ├─ Ad Set C1: SUCCESS (created)
  │   └─ Ad C1a: FAILED (creative rejected)
  └─ Ad Set C2: SUCCESS (created)
      └─ Ad C2a: SUCCESS (created)
Result:
  • Campaign A: Fully published and live
  • Campaign B: Not published (fix budget and retry)
  • Campaign C: Partially published (fix Ad C1a and retry)
Successful entities remain live on the platform even if other entities fail. You don’t need to republish successful entities when retrying failures.

Retry Workflow for Failed Campaigns

When publishing fails, you can fix errors and retry without affecting successful entities.

How Retry Works

1

Review error messages

Click failed nodes to see detailed error messages explaining what went wrong.
2

Fix the issues

Update node configurations to resolve the errors. This might involve changing budgets, updating creative, or reconnecting platforms.
3

Retry publishing

Click Publish again. Whathead will only attempt to publish entities that failed or haven’t been published yet.
4

Successful entities skipped

Entities that succeeded in the previous publish are automatically skipped. No duplicate entities are created.

Retry Example

First Publish Attempt:
Campaign A: SUCCESS (created, receives ID: camp_123)
Ad Set A1: FAILED (targeting too narrow)
After Fixing Error:
Campaign A: SKIP (already has ID: camp_123, no changes)
Ad Set A1: CREATE (no ID yet, will be created)
Result:
  • Campaign A is not duplicated
  • Ad Set A1 is created under the existing Campaign A
  • No unnecessary API calls for Campaign A
Whathead tracks which entities succeeded and automatically skips them during retry. You don’t need to manually exclude successful entities.

Common Retry Scenarios

Scenario: Campaign was created successfully, but ad set failed due to validation error.Retry behavior:
  • Campaign: SKIP (already created)
  • Ad set: CREATE (fix error and create)
  • Ads: CREATE (will be created under the new ad set)
Result: Ad set and ads are added to the existing campaign.
Scenario: Campaign and ad set were created, but ad failed due to creative rejection.Retry behavior:
  • Campaign: SKIP (already created)
  • Ad set: SKIP (already created)
  • Ad: CREATE (fix creative and create)
Result: Ad is added to the existing ad set.
Scenario: You published 5 campaigns, 3 succeeded, 2 failed.Retry behavior:
  • Successful campaigns: SKIP (all entities already created)
  • Failed campaigns: CREATE (fix errors and create)
Result: Only failed campaigns are published, successful ones are not duplicated.
Scenario: Campaign failed, so ad sets and ads were not published.Retry behavior:
  • Campaign: CREATE (fix error and create)
  • Ad sets: CREATE (will be created after campaign succeeds)
  • Ads: CREATE (will be created after ad sets succeed)
Result: Entire campaign structure is created in hierarchical order.

Cross-Platform Transfer Publishing Behavior

When you transfer campaigns between platforms, publishing behavior depends on how you perform the transfer.

Transfer by Copy/Paste

When you copy a campaign from one platform and paste it to create a campaign for another platform:
1

Copy campaign

Select the campaign structure and copy it (Ctrl+C or Cmd+C).
2

Paste campaign

Paste the campaign (Ctrl+V or Cmd+V). Platform IDs are cleared automatically.
3

Change platform

Update the campaign configuration to select the new platform.
4

Adjust settings

Update platform-specific settings (objectives, targeting, creative) to match the new platform’s requirements.
5

Asset migration

Creative assets from the original campaign are automatically migrated to the new platform during publish. If migration fails, manually upload compatible assets.
6

Publish

Click Publish. All entities CREATE new on the new platform.
Result:
  • Original campaign on Platform A: Unchanged
  • New campaign on Platform B: Created with all ad sets and ads
  • Creative assets: Automatically migrated (or manually uploaded if migration fails)

Transfer Using Cross-Platform Transfer Feature

When you use Whathead’s cross-platform transfer feature:
1

Select campaign

Select the campaign you want to transfer.
2

Choose transfer

Click “Transfer to Platform” and select the destination platform.
3

Map settings

Whathead automatically maps compatible settings and flags incompatible ones for your review.
4

Adjust as needed

Update any settings that don’t transfer directly.
5

Publish

Click Publish. All entities CREATE new on the destination platform.
Result:
  • Original campaign on Platform A: Unchanged
  • New campaign on Platform B: Created with mapped settings
Cross-platform transfer is more efficient than manual copy/paste because it automatically maps compatible settings and identifies incompatibilities.

What Transfers and What Doesn’t

When transferring campaigns between platforms: Always transfers:
  • Campaign name
  • Budget amounts (adjusted for platform minimums)
  • Schedule dates
  • Ad copy text
  • Destination URLs
Sometimes transfers:
  • Objectives (if equivalent exists on destination platform)
  • Targeting (if compatible with destination platform)
  • Creative assets (if they meet destination platform specs)
Never transfers:
  • Platform IDs (always cleared)
  • Platform-specific settings (special ad categories, pixel IDs, etc.)
  • Custom audiences (must be recreated on destination platform)
Learn more: Cross-Platform Transfer

Understanding the Preview

Before publishing, Whathead shows a preview of what will happen for each entity. The preview displays CREATE, UPDATE, or SKIP for each node.

Preview Example

Campaign: "Summer Sale 2024" → UPDATE (has ID, has changes)
  ├─ Ad Set: "US Audience 18-35" → SKIP (has ID, no changes)
  │   ├─ Ad: "Beach Photo Variant A" → UPDATE (has ID, has changes)
  │   └─ Ad: "Beach Photo Variant B" → CREATE (no ID)
  └─ Ad Set: "UK Audience 25-45" → CREATE (no ID)
      └─ Ad: "City Photo Variant A" → CREATE (no ID)
Interpretation:
  • Campaign will be updated (you changed the budget)
  • First ad set will be skipped (no changes)
  • First ad under first ad set will be updated (you changed the copy)
  • Second ad under first ad set will be created (new ad)
  • Second ad set and its ad will be created (new ad set)
Always review the preview before confirming. It shows exactly what will happen and helps you catch unexpected CREATE or UPDATE actions.

Best Practices

Avoid Accidental Duplicates

Do:
  • Use Select Existing or Expand to load campaigns you want to update
  • Check for green platform ID indicators before publishing
  • Review the preview to confirm UPDATE actions for campaigns you want to update
Don’t:
  • Republish canvas-origin campaigns expecting them to update (they’ll create duplicates)
  • Reconnect nodes unless you intend to create duplicates
  • Copy/paste campaigns you want to update (paste clears IDs)

Manage Partial Failures Efficiently

Do:
  • Fix errors immediately and retry
  • Review error messages carefully to understand what went wrong
  • Use the preview to confirm only failed entities will be retried
Don’t:
  • Delete successful entities and start over
  • Manually exclude successful entities (Whathead does this automatically)
  • Ignore partial failures (fix them promptly)

Handle Cross-Platform Transfers Correctly

Do:
  • Use copy/paste or the transfer feature to move campaigns between platforms
  • Verify all settings are compatible with the destination platform
  • Test with one campaign before transferring many
Don’t:
  • Expect platform IDs to transfer (they’re always cleared)
  • Assume all settings will transfer automatically (review and adjust)
  • Publish without checking the preview

Troubleshooting

Cause: The campaign was a canvas-origin node without a platform ID, so each publish created a new entity.Resolution:
  1. Delete the duplicate campaigns in the platform portal
  2. To update the campaign in the future, load it using Select Existing
  3. Alternatively, note the platform ID after first publish and don’t republish canvas-origin nodes
Cause: The node didn’t have a platform ID, so it created new instead of updating.Resolution:
  1. Delete the new campaign in the platform portal
  2. Load the campaign you wanted to update using Select Existing
  3. Make your changes and publish to update the existing campaign
Cause: Partial success is normal when some entities have errors.Resolution:
  1. Review error messages on failed entities
  2. Fix the errors
  3. Click Publish again—successful entities will be skipped automatically
  4. Only failed entities will be retried
Cause: Cross-platform transfer always creates new entities on the destination platform.Resolution: This is expected behavior. Cross-platform transfer creates new campaigns on the destination platform and leaves the original unchanged. If you want to update the original campaign, don’t use transfer—edit it directly and republish.
Cause: The node doesn’t have a platform ID, so it will create new.Resolution:
  1. Check if the node has a platform ID (look for the ID in node details)
  2. If you want to update an existing entity, load it using Select Existing
  3. If you want to create new, proceed with the publish

Next Steps