Cloning

Overview

Cloning lets you duplicate complex records — packages, services, promotions, itineraries — without rebuilding them from scratch. Instead of creating a new package and manually recreating dozens of components, options, price seasons, and schedules, you clone the original and adjust what differs.

Kaptio provides dedicated clone operations for each major record type. Each clone controller extends a shared framework (SuperClone) that handles the mechanics of deep-copying object hierarchies, reparenting child records to point at the new parent, and stripping fields that should not carry over (such as booking-specific data).

This guide covers what each clone operation copies, what it skips, the flags that control behavior, and the validation steps you should follow after cloning.

Prerequisites

Before cloning any record, ensure:

• You have Admin or Product Manager access in Kaptio
• The source record is in a stable, validated state — cloning copies problems along with data
• You understand the structure of the record you are cloning (Package Fundamentals, Supplier & Service Setup, Cost & Pricing Architecture)

---

Part 1: The SuperClone Framework

All clone operations in Kaptio are built on a shared base class called SuperClone. Understanding this framework helps you predict behavior across every clone type.

How SuperClone Works

SuperClone manages three core concerns:

1. Deep copy — Walks the object hierarchy from the source record, creates new copies of each child record, and links them to the newly created parent.
2. Reparenting — When child records reference other children (not just the parent), SuperClone maintains reparenting maps to update those cross-references. For example, if a Component Option references a Price Season, the cloned option must reference the cloned Price Season, not the original.
3. Field exclusion — Each clone controller defines a set of fields that should not be copied. Booking-specific fields, external IDs, and status fields are typically excluded so the clone starts clean.

Field Exclusion

SuperClone maintains per-object sets of fields to ignore during cloning. These typically include:

• Booking count and revenue rollup fields
• External integration IDs
• Approval and workflow status fields
• Timestamps that should reflect the new record’s creation

This means you get a structurally complete copy without inheriting operational state from the original.

Custom Field Exclusion (Fields To Ignore Fieldset)

In addition to the fields Kaptio excludes automatically, admins can exclude their own fields from cloning using a fieldset called Fields To Ignore (API name: Fields_To_Ignore).

Any field added to this fieldset on a given object will be stripped during cloning — the cloned record will not carry over the value from the original. This is useful when an org has custom fields that should always start blank on a new clone (for example, a custom external reference or a flag that only applies to the original record).

How it works:

• During every clone operation, the cloning engine checks whether a fieldset named Fields_To_Ignore exists on the object type being cloned.
• If the fieldset exists, all fields listed in it are removed from the copy — they will be null on the cloned record.
• If no fieldset with that name exists on the object, the check is silently skipped and has no effect.

Which record types does it work with?

The Fields_To_Ignore fieldset works with every object type that Kaptio clones — Packages, Services (Items), Promotions, Discounts, Itineraries, and their child objects. The cloning engine, the amendment cloning service, and the general SObject copy utility all perform the same lookup.

However, Kaptio only ships this fieldset on the Itinerary object (Itinerary__c) out of the box, with two available fields:

Field	API Name
Lock Sell Price Mode	LockSellPriceMode__c
Usable As Template	UsableAsTemplate__c

For Itinerary and Amendment cloning, the fieldset works immediately — just add fields to it. For other objects (Package, Item, Promotion, etc.), the fieldset would need to be created on that object with the exact name Fields_To_Ignore before it takes effect.

To configure:

1. Navigate to Setup → Object Manager → [Object Name] → Field Sets.
2. Open the Fields To Ignore fieldset (or create one with API name Fields_To_Ignore if it does not exist on the object).
3. Drag the fields you want excluded into the fieldset.
4. Save — the next clone operation on that object will skip those fields.

---

Part 2: Service (Item) Cloning

Service cloning duplicates a service record and its related data. Unlike package cloning, most related data is opt-in — you choose what to include via granular flags.

What Gets Cloned

Object	API Name	Always Cloned	Condition
Service (Item)	KaptioTravel__Item__c	Yes	—
Linked Services	Related KaptioTravel__Item__c	No	Only when cloneLinkedServices is enabled
Time Schedules	Schedule records	No	Only when cloneTimeSchedules is enabled
Notes	Note records	No	Only when cloneNotes is enabled
Content & Media	Content/media records	No	Only when cloneContentAndMedia is enabled
Inventory	KaptioTravel__InventorySeasonStatusAssignment__c	No	Only when cloneInventory is enabled
Item Prices	KaptioTravel__Item_Price__c	No	Only when cloneItemPrices is enabled
Price Category Assignments	KaptioTravel__ItemPriceCategoryAssignment__c	Follows	Cloned alongside Item Prices when price-related flags are enabled

Clone Flags

All service clone flags default to disabled — you must explicitly opt in:

Flag	Default	Effect
cloneLinkedServices	Disabled	Includes linked/child service records
cloneTimeSchedules	Disabled	Includes time schedule configuration
cloneNotes	Disabled	Includes note records attached to the service
cloneContentAndMedia	Disabled	Includes content blocks and media assets
cloneInventory	Disabled	Includes inventory season status assignments
cloneItemPrices	Disabled	Includes item price records and price category assignments

Async Cloning

Service cloning supports an async mode (asyncClone flag). Use async cloning when the source service has a large volume of related records — particularly extensive pricing or inventory data. Async cloning processes the duplication in the background, avoiding governor limit issues on large datasets.

After Cloning a Service

1. Rename the cloned service.
2. Review which flags you enabled — if you skipped inventory or pricing, you will need to set those up manually on the clone.
3. Check price category assignments — ensure the cloned service has the correct price categories for its intended use.
4. Validate inventory contracts — if inventory was cloned, verify date ranges and allotment levels are appropriate for the new service.

---

Part 3: Package Cloning

Package cloning is the most commonly used clone operation. It duplicates an entire package — its component structure, options, pricing configuration, and schedules — into a new package record.

What Gets Cloned

Object	API Name	Always Cloned	Condition
Package	KaptioTravel__Package__c	Yes	—
Component	KaptioTravel__Component__c	Yes	—
Component Option	KaptioTravel__ComponentOption__c	Yes	—
Price Season	KaptioTravel__PriceSeason__c	Yes	—
Package Schedule	KaptioTravel__PackageSchedule__c	Conditional	Only when copyPackageDepartureOrSeason is enabled
Package Departure	KaptioTravel__PackageDeparture__c	Conditional	Only when copyPackageDepartureOrSeason is enabled
Time Period	KaptioTravel__TimePeriod__c	Conditional	Cloned via parent record — always included when linked to a Price Season; only included when linked to a Package Schedule if copyPackageDepartureOrSeason is enabled
Package Price	KaptioTravel__PackagePrice__c	Conditional	Only when copyPricesFromPriceManager is enabled AND Lightning Costings is NOT active
Service Level Assignment	KaptioTravel__PackageServiceLevelAssignment__c	Yes	—
Allotment Category Assignment	KaptioTravel__AllotmentCategoryComponentAssignment__c	Yes	—

Clone Flags

Two flags control optional behavior during package cloning:

Flag	Default	Effect
copyPackageDepartureOrSeason	Enabled	When enabled, Package Departure and Package Schedule records are included in the clone. Disable this if you want to define new departure dates or seasons from scratch.
copyPricesFromPriceManager	Enabled	When enabled, Package Price records are cloned — but only if Lightning Costings is not active on the org. If Lightning Costings is enabled, package-level prices are managed differently and this flag has no effect.

Reparenting During Package Clone

Package cloning involves several cross-references that must be updated to point at the cloned records rather than the originals:

• Price Season references — Component Options and Package Prices that reference a Price Season are reparented to the cloned Price Season.
• Primary Component Option references — Records that reference a primary Component Option are reparented to the cloned option.
• Secondary Component Option references — Same as above, for secondary option references.

This bidirectional reparenting ensures the cloned package is fully self-contained with no dangling references back to the source.

After Cloning a Package

1. Rename the cloned package — it will have the same name as the original.
2. Review components and options — verify the structure matches your intent.
3. Check departure dates / seasons — if you cloned with copyPackageDepartureOrSeason enabled, update dates for the new package’s time frame.
4. Validate pricing — open the Price Manager and confirm price seasons and package prices are correct.
5. Set the package to Inactive until setup is fully validated — cloned packages should not go live without review.

---

Part 4: Other Clone Operations

Promotion Cloning

Duplicates a promotion record along with its associated rules, effects, and combinability settings. Use this when creating a similar promotion for a new season or campaign — clone the original, then adjust the dates, discount values, and qualifying conditions.

What Gets Cloned

Object	API Name	Cloned	Notes
Promotion	KaptioTravel__Promotion__c	Yes	Root record — scope, effect handling, and effects-max are carried over from the original if not set on the new record
Promotion Rule	KaptioTravel__PromotionRule__c	Yes	All rules are copied and reparented to the new promotion
Promotion Rule Operand	KaptioTravel__PromotionRuleOperand__c	Yes	Operands are copied and reparented to the corresponding cloned rule
Promotion Effect	KaptioTravel__PromotionEffect__c	Yes	All effects are copied and linked to the new promotion
Combinability Group Assignment	KaptioTravel__CombinabilityGroupAssignment__c	Yes	Group assignments are copied to maintain combinability configuration

All child records are cloned automatically — there are no opt-in flags for promotion cloning. If any of these records are missing after a clone, it is a permissions or visibility issue, not expected behavior. See Effects missing after cloning a promotion in Common Issues below.

Discount Cloning

Duplicates discount records. Useful when setting up similar discount structures across multiple products or channels.

Itinerary Cloning

Duplicates an itinerary record. This is used internally for amendments — when a booking needs to be modified, the system clones the current itinerary to create an amended version while preserving the original as a record.

Itinerary cloning supports both synchronous and asynchronous modes. For itineraries with extensive content, the async variant avoids timeout issues.

Itinerary Content Cloning

Duplicates itinerary content records independently of the itinerary itself. Used when content needs to be replicated across itineraries without cloning the full itinerary structure.

Price Season Cloning

Duplicates Price Season records (API name: Price_Period__c). Use this when setting up pricing for a new season that mirrors an existing one — clone the Price Seasons and adjust the dates and values.

Note Cloning

Duplicates note records from one parent record to another. Notes are copied as standalone records attached to the target parent.

---

Part 5: What Is Never Cloned

Across all clone operations, certain data is intentionally excluded:

• Booking data — Reservation counts, revenue totals, and guest records are never carried to the clone.
• Approval and workflow state — Status fields, approval timestamps, and workflow flags are reset.
• External system IDs — Integration identifiers (payment references, channel-specific IDs) are stripped to prevent conflicts.
• Audit timestamps — Created/modified dates reflect the clone operation, not the original record’s history.

This ensures every clone starts as a clean, unburdened copy ready for configuration.

---

Part 6: Validation Checklist

After any clone operation, walk through this checklist before activating the cloned record:

Step	Check	Why
1	Record renamed with correct new name	Avoids confusion with the original
2	All child records present and correctly linked	Confirms the deep copy completed
3	Cross-references point to cloned children, not originals	Validates reparenting worked correctly
4	Pricing is correct for the cloned context	Dates, seasons, and values may need adjustment
5	Inventory contracts have correct date ranges	Cloned dates likely need updating for the new time period
6	Access rules and visibility settings are appropriate	The clone may need different channel or account restrictions
7	Record is set to Inactive / Draft	Prevents the clone from appearing in search or bookings before it is ready
8	Test a booking or quote against the clone	End-to-end validation that pricing, availability, and structure work together

---

Common Issues

Clone appears to complete but child records are missing

This typically occurs when the source record has a large number of children and the synchronous clone hits governor limits. For services, enable the asyncClone flag. For itineraries, use the async clone variant. Re-run the clone in async mode and verify all children are present.

Pricing shows as zero or “Unpriced” on the clone

If copyPricesFromPriceManager was disabled during package cloning — or if Lightning Costings is active on the org — package-level prices are not copied. You will need to configure pricing through the Price Manager on the cloned package. For service clones, check that cloneItemPrices was enabled.

Cloned package still references original Price Seasons

This indicates a reparenting issue. Check the Price Season lookup fields on Component Options and Package Prices in the cloned package. They should reference the cloned Price Seasons (which will have new IDs), not the originals. If they reference the originals, the clone may not have completed successfully — re-clone.

Effects missing after cloning a promotion

Promotion cloning is designed to copy all effects, rules, rule operands, and combinability group assignments automatically. If effects are missing on the cloned promotion, the most likely cause is a sharing or permissions issue. The clone controller runs with sharing, which means the user performing the clone must have read access to the original Promotion Effect records. Check the following:

• Object-level access — confirm the user’s profile or permission set grants Read access to the PromotionEffect__c object.
• Field-level security — ensure no required fields on PromotionEffect__c are hidden from the user’s profile, which could cause the insert of cloned effects to silently fail.
• Sharing rules / OWD — if the org-wide default for Promotion Effect is Private, the user may not have visibility to the original effects. Verify the user can see the effects on the source promotion before cloning.

Departures or schedules missing from clone

The copyPackageDepartureOrSeason flag must be enabled during package cloning to include Package Departure and Package Schedule records. If you need departures on the clone, either re-clone with the flag enabled or create new departures manually.

---

Schema Reference

Key objects involved in cloning operations:

Object	API Name	Role in Cloning
Package	KaptioTravel__Package__c	Root record for package cloning
Component	KaptioTravel__Component__c	Child of Package — always cloned with package
Component Option	KaptioTravel__ComponentOption__c	Child of Component — always cloned; reparented to cloned Price Season
Price Season	KaptioTravel__PriceSeason__c	Pricing time window — always cloned with package
Package Schedule	KaptioTravel__PackageSchedule__c	Departure schedule — conditionally cloned
Package Departure	KaptioTravel__PackageDeparture__c	Specific departure — conditionally cloned
Time Period	KaptioTravel__TimePeriod__c	Date range definition — cloned via parent (Price Season or Package Schedule)
Package Price	KaptioTravel__PackagePrice__c	Package-level pricing — conditionally cloned
Service Level Assignment	KaptioTravel__PackageServiceLevelAssignment__c	Service tier linkage — always cloned
Allotment Category Assignment	KaptioTravel__AllotmentCategoryComponentAssignment__c	Inventory category linkage — always cloned
Service (Item)	KaptioTravel__Item__c	Root record for service cloning
Item Price	KaptioTravel__Item_Price__c	Service pricing — conditionally cloned
Price Category Assignment	KaptioTravel__ItemPriceCategoryAssignment__c	Occupancy/category linkage — follows item prices
Inventory Season Status	KaptioTravel__InventorySeasonStatusAssignment__c	Inventory availability — conditionally cloned
Promotion	KaptioTravel__Promotion__c	Root record for promotion cloning

---

See Also

• Package Fundamentals — the structure that package cloning duplicates
• Supplier & Service Setup — the foundation for service cloning
• Cost & Pricing Architecture — how pricing interacts with cloned records
• Fixed Departures — departure-specific context for package clone flags
• Seasonal Setup — season-specific context for package clone flags