Nest QCDR Tokens Inside Other Tokens Safely

QCDR Tokens can reuse other Tokens by placing a normal {token.name} reference inside the outer Token's content. Nesting is useful for shared values such as organization names, URLs, reusable HTML fragments, and other content that should be maintained in one place.

Nesting also creates a real dependency. The outer Token is available only when its required inner Tokens are available in the current request, and its effective plan requirement rises to the highest requirement in the dependency chain.

Create a Nested Token

  1. Create the reusable inner Token first and save it with a stable name such as {company.name}.
  2. Create or edit the outer Token.
  3. In the Token content, place the inner Token where its output belongs. For example: Welcome to {company.name}.
  4. Keep the outer Token in Draft while you test its dependencies and targeting.
  5. Save the outer Token. QCDR records Token references as dependencies so usage and deletion safeguards can recognize them.
  6. Enable the outer Token only after the complete chain resolves in the pages and audiences where it will be used.

Plan Requirements Are Inherited

A Token that contains another Token reference requires at least Pro, even when the outer output type would otherwise be Basic. If any referenced Token requires Max, the outer Token also requires Max. Targeting can raise the requirement further: extension/audience targeting and enabled schedules require at least Pro, while IP rules or technical conditions require Max.

This enforcement is recursive. Downgrading the site does not erase the Token definitions, but a dependency chain that is no longer plan-eligible does not resolve on the frontend.

Every Dependency Must Be Available

QCDR checks the complete dependency chain in the current request. A referenced Token must be Enabled, permitted by the current Effective tier, inside its page/extension/audience/schedule/IP/condition scope, and able to obtain any dynamic data it needs.

If an inner Token is unavailable, the outer Token is treated as unavailable for that location. A directly authored outer placeholder remains unchanged, and a Rule that depends on the Token leaves its original matched content unchanged instead of replacing it with a partial value.

Cycle and Depth Protection

Do not create circular references such as {token.a} using {token.b} while {token.b} uses {token.a}. QCDR detects circular dependency paths and stops them safely.

The current runtime also limits nested Token resolution to eight levels. This protects a page request from runaway dependency chains. Keep nesting shallow and use clear names so administrators can understand the chain without tracing many layers.

Verify the Chain Before Production Use

  • Test the outer Token directly in a page where every dependency should qualify.
  • Test a context where one dependency intentionally does not qualify and confirm authored content is preserved.
  • If the outer Token is used by a Rule, verify that the Rule target remains unchanged when the dependency is unavailable.
  • Before deleting an inner Token, check its Token Library reference count and remove or replace all dependent references first.

Community Discussion

Want to compare workflows, share practical tips, or discuss how you use this QCDR feature? Visit the QC Dynamic Replacer Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.