Cloning Tables

Available to: Developers, Admins Minimum plan: Business (requires multiple branches)

Cloning copies a table definition — including all its column definitions and import mappings — from a higher branch to a lower branch. In GIT you would create a new feature branch that has all code from the main branch. IN TitanRDM you effectively cherry pick the table definition you want to change into your private dev branch. Note, tables can only be changed in a Private Dev branch. They can't be changed directly in a Shared branch (i.e. Test, Production).

Clone dialog

Prerequisites

  • Developer permission on the source table's domain
  • Edit permission on the target branch
  • The target branch must be open
  • The target branch must exist in the promotion path of the higher branch.
  • Business or Enterprise plan (cloning requires multiple branches)

Cloning a Single Table

  1. Navigate to Development > Table Definitions
  2. Find the table definition you want to clone
  3. Click on the table to open its detail page
  4. Click Clone in the toolbar
  5. In the clone dialog:
    • Select the target branch from the dropdown (lists your private branches)
    • Branches where a copy already exists are indicated
  6. Click Clone

TitanRDM creates a complete copy of the table definition on the target branch, including:

  • All column definitions (names, types, constraints, order)
  • Import mappings and their column mappings
  • Lookup display column setting

The cloned definition appears as requiring deployment on the target branch.

Bulk Cloning

To clone multiple table definitions at once:

  1. Navigate to Development > Table Definitions
  2. Select multiple tables using the checkboxes
  3. Click Clone in the toolbar
  4. Select the target branch
  5. Click Clone

Dependency Ordering

When bulk cloning, TitanRDM automatically orders the tables by foreign key dependencies. If Table A references Table B, Table B is cloned first. This ensures foreign key references are correctly wired on the target branch.

External Reference Validation

Before bulk cloning proceeds, TitanRDM validates that all referenced tables (via foreign keys) either:

  • Are included in the current bulk clone selection, or
  • Already exist on the target branch (matched by key)

If a referenced table is missing from both the selection and the target branch, the clone is blocked with an error message explaining which table needs to be cloned first.

What Gets Cloned

IncludedNot Included
Table definition properties (name, domain, database table name, load type, description)Row data in the physical table
All column definitions (including deleted ones)Deployment history
Import mappings and column mappingsPromotion history
Lookup display column referencePhysical table (must be deployed separately)
Foreign key references (re-pointed to target branch equivalents)

Foreign Key Handling

When a table is cloned, foreign key references in column definitions are re-pointed to the equivalent table on the target branch:

  1. TitanRDM finds the source table's FK reference (e.g., column country_code references Country Codes table on the source branch)
  2. It looks for a table with the same key on the target branch
  3. If found, the cloned column's FK is pointed to the target branch's copy
  4. If not found, the FK reference is cleared to avoid dangling cross-branch references

This is why dependency ordering and reference validation matter — clone referenced tables before tables that depend on them.

Clone Validation

TitanRDM performs additional validation before cloning:

Unpromoted Changes Check

If the table you are cloning from a shared branch (e.g., Development) has unpromoted changes on a downstream branch (e.g., Test has changes that haven't been promoted to Production yet), TitanRDM warns you. This prevents you from accidentally cloning an older version when a newer version exists further down the branch hierarchy.

The warning message directs you to clone from the branch that has the most recent changes.

Clone vs Promote

ClonePromote
DirectionParent branch to Child branch (downward only)Child branch to parent branch (upward only)
ApprovalNo approval requiredRequires approver on target branch
Diff reviewNo diff shownFull diff review
Audit trailCloneAction record createdFull promotion lifecycle with actions
Use caseBringing definitions into a private development branch for developmentMoving tested changes through environments toward production

When to Clone

  • Copying a table definition from a shared branch (Dev/Test/Prod) into your private feature branch to work on it
  • Bringing a reference table into a new branch so that FK dependencies are satisfied

When to Promote

  • Moving changes through the standard development lifecycle (Dev → Test → Prod)

After Cloning

After a table definition is cloned to the target branch:

  1. Switch to the target branch
  2. The cloned table appears in Table Definitions with a "Needs Deploy" badge
  3. Make any additional modifications if needed
  4. Deploy to create or update the physical table on the target branch

Related Pages