Clone a rule

Last updated: May 19, 2026

Clone a rule

Per-rule action menu → Duplicate. Backed by POST /api/v1/rules/:id/duplicate (verified). Creates an exact copy with (copy) suffix in name, status: paused, execution_count: 0, last_evaluated_at: null. The cloned rule is independent — edits don't propagate back to the original.

Who is this for

Anyone managing more than one rule. Especially:

  • Variant testing (clone + tweak threshold + compare execution histories)

  • Per-account rules (clone an account-A rule for account B)

  • Template-from-rule (clone a working rule + adjust for a new use case)

  • Staging changes (clone, edit, preview, activate; keep original as fallback)

How to clone

From the rule list

/rules → row actions menu → Duplicate.

From rule detail

/rules/:id → top toolbar → Duplicate.

Via API

POST /api/v1/rules/:id/duplicate — no body needed. Returns the new rule with a fresh id.

What gets copied

Everything that defines the rule's behavior:

  • name (+ (copy) suffix)

  • description

  • entity_level

  • ad_account_ids[], entity_filter

  • condition_logic, conditions[]

  • actions[]

  • schedule_type, interval_minutes, schedule_config

  • cooldown_minutes, max_executions_per_day, budget_change_limit_pct, budget_daily_cap

  • notify_on_execution, notify_channels

  • platforms[]

  • template_id (if cloning a template-derived rule)

What gets reset

  • id — new UUID

  • status → paused (always, regardless of source rule's status)

  • execution_count → 0

  • error_count → 0

  • last_evaluated_at → null

  • last_executed_at → null

  • last_error → null

  • auto_paused_at → null

  • cb_reset_after → null

  • created_at, updated_at → now

The clone is "born new" — no inherited history or circuit-breaker state.

Use cases

Variant testing (A/B thresholds)

Original: kill losers, CPA > 30. Clone: kill losers, CPA > 25 (stricter). Run both for 2 weeks → compare execution histories → keep the better-performing one, delete the other.

Scope must be disjoint (otherwise both rules act on the same entity → conflicts). Either:

  • Different scopes (different ad accounts)

  • Same scope but coordinated (deactivate original while testing clone)

Per-account rules

ClientA has a rule "Scale winners — ROAS > 3 / 3d / +20%". Clone it. Edit clone: scope = ClientB account. Done. Same logic, different scope.

Scales much better than rewriting per-client.

Template-from-rule

You've tuned a rule that works great. Want to reuse the pattern.

  • Clone the working rule

  • Edit name + description to be generic

  • (Optionally) save as workspace template (if your admin enables this)

Staging changes

Existing rule fires daily; need to change a threshold. Instead of editing live:

  • Clone the rule

  • Edit the threshold on the clone

  • Preview the clone

  • When satisfied: activate the clone, pause the original

  • After 1-2 weeks: delete the original

Zero-downtime tuning.

After cloning

Immediately:

  1. Rename — replace (copy) with a meaningful suffix or full rename

  2. Adjust scope if cloning for a different account/client

  3. Preview to verify scope + conditions work for new context

  4. Activate when ready

Conflict prevention

Two rules with overlapping scope and conflicting actions cause problems (e.g. one pauses, another activates). Always:

  • Make scopes disjoint, OR

  • Make actions complementary (notify_only on one, real action on the other), OR

  • Coordinate (only one active at a time)

RBAC + audit

Mediabuyer+ can clone. Audit log entry: action: rule_duplicate with metadata: {source_rule_id, new_rule_id}.

Common mistakes

  • Clone + forget to change scope: both rules act on the same entities → conflicts

  • Clone + leave (copy) suffix: clutter; rename promptly

  • Cloning instead of editing: if you really want the change live now, just edit the original. Clone is for staging or variants.

  • Cloning a rule in error status: clone starts fresh (no error inherited), but the same upstream issue may trip it again. Fix the cause first.

Related