Parameters in the dashboard

The Parameters page lists every parameter in the project. Use it to inspect what exists, where it’s used, and how it’s currently being overridden.

​

The list

Each row shows:

• Key — the dot-namespaced name (checkout.button.color)
• Type — string, number, boolean, json
• Layer — the layer this parameter belongs to
• Default — the canonical default value
• Status — synced (managed by CLI) or dashboard-only
• Active policies — how many running policies are currently overriding this parameter

Filter by layer, type, status, or name. The status filter is useful when you’re cleaning up — dashboard-only parameters can be imported into your repo via the CLI.

​

Synced vs dashboard-only

Synced parameters are defined in .traffical/config.yaml and pushed via the CLI. Their definitions are read-only in the dashboard — the default, type, description, and constraints are managed in code. The dashboard lets you create policies on top of them but won’t let you edit their definitions. Dashboard-only parameters are created in the UI. They’re editable in both directions. To bring one into code, run traffical import param <key> — the CLI pulls the definition into your .traffical/config.yaml and marks it as synced going forward.

​

Parameter detail

Clicking a parameter opens the detail page. You’ll see:

• The full definition (key, type, default, constraints, description)
• The layer it belongs to
• A history of value changes
• All policies that override this parameter, with their current state and allocations
• Recent exposure volume per allocation (if there are any active policies)

If the parameter is dashboard-only, you can edit the default, change the description, add or update constraints, and move it to a different layer. If it’s synced, you can do those things via .traffical/config.yaml and traffical push.

​

Moving a parameter to a different layer

Open the parameter detail page → Move to layer → pick the destination. Moving a parameter reshuffles its bucket assignments — users that were in treatment for an active experiment may move to control (or vice versa). Don’t move parameters mid-experiment.

​

Archiving and deleting

A synced parameter that gets removed from .traffical/config.yaml stays in the platform unless you traffical push --prune, which archives it. Archived parameters don’t appear in the default list — filter by Archived to see them. Dashboard-only parameters can be archived from the detail page. Archived parameters can be restored within 30 days; after that they’re permanently deleted.

​

The base layer

Every project has a base layer that holds parameters not assigned to any other layer. New CLI-pushed parameters land here by default. The base layer can’t be deleted.

​

Next steps