UX 2.0

Overview

The UX 2.0 Configuration APIs are the top-level orchestration layer in Cisco SD-WAN Manager. Configuration is hierarchical and modular: parcels sit inside feature profiles, and feature profiles are grouped inside a configuration group, which is then assigned to devices.

The three group types

Group	What it does	Supported solutions
Configuration Group	Groups all feature profiles (System, Transport, Service, CLI) and assigns them to devices	sdwan, sd-routing, mobility, nfvirtual, service-insertion, cellulargateway
Policy Group	Groups policy-related profiles and assigns them to devices	sdwan, sd-routing
Topology Group	Defines hub-spoke or mesh topology overlays across the fabric	sdwan

Configuration hierarchy

A Configuration Group is built from four types of Feature Profile, each responsible for a different layer of device configuration:

Feature Profile	Scope
System	System-level settings: AAA, NTP, BFD, OMP, Logging, Banner, etc.
Transport	Underlay connectivity: WAN interfaces, VPN 0, routing
Service	LAN-side services: VPN 1+, routing, policies
CLI	Raw CLI configuration (optional, for unsupported features)

Each profile is populated by Feature Parcels — individual, typed configuration blocks (e.g. an NTP parcel, an AAA parcel). You create the profile first, then attach parcels to it.

Once profiles and parcels are ready, you attach the configuration group to devices and deploy:

1. Associate devices to the Configuration Group
2. Set per-device variables
3. Preview the rendered configuration
4. Deploy — returns a parentTaskId for tracking

Workflow

1. Create a System Feature Profile → returns System Profile Identifier
2. Create a Transport Feature Profile → returns Transport Profile Identifier
3. Create a Service Feature Profile → returns Service Profile Identifier
4. Create a CLI Feature Profile → returns CLI Profile Identifier (optional)
5. Create the Feature Parcels for each Feature Profile → returns Parcel Identifier

For a System Feature Profile this would be: AAA, Banner, BFD, NTP, OMP, Logging, Global, MRF — each returning a parcelId.

Detailed Steps

1. Create Feature Profiles (System, Transport, Service…) → Returns profile UUIDs
2. Create Feature Parcels under each Profile — AAA, Banner, BFD, NTP, OMP, VPN, etc.
3. Create Configuration Group referencing Profile UUIDs → Returns configGroupId
4. Associate Devices to the Configuration Group → Binds device UUIDs to the group
5. Fetch & Assign Device Variables → Fill in per-device template variables
6. (Optional) Preview Device Configuration → Returns rendered CLI/config for verification
7. Deploy Configuration Group → Returns parentTaskId for tracking
8. (Optional) Create & Deploy Policy Group
9. (Optional) Create & Deploy Topology Group
10. Track task: GET /dataservice/device/action/status/{parentTaskId}

The optionType Pattern

Most UX 2.0 feature parcel fields use an optionType wrapper. This tells SD-WAN Manager whether the value is fixed in the parcel, left at its default, or exposed as a deploy-time variable.

optionType	Meaning	When to use it
global	Store a concrete value directly in the parcel	Good for lab values or settings that should be identical on every device
variable	Store a variable placeholder that must be filled during device assignment/deployment	Good for production templates reused across many devices
default	Use the Manager/default schema value	Good when the default behavior is acceptable

Bruno variables vs. SD-WAN variables

Bruno variables and SD-WAN deploy-time variables are different things.

When a Bruno request contains "value": "{{aaa_password}}", Bruno replaces {{aaa_password}} before the request is sent. If the field uses "optionType": "global", SD-WAN Manager receives the actual password value and stores it directly in the parcel. That field will not appear later in the Configuration Group device variables response.

Only fields created with "optionType": "variable" become SD-WAN deploy-time variables that must be assigned through the Configuration Group variables API.

In this lab, many values use global even when they come from Bruno environment variables. That keeps the workflow simple for a single sandbox edge device: Bruno substitutes the value, Manager stores it in the parcel, and the deployment variable step only needs true device variables such as host_name, system_ip, site_id, and pseudo_commit_timer.

In production, you would usually use variable for device-specific values such as interface IP addresses, site-specific settings, and passwords. That allows the same Feature Profiles and Configuration Group to be reused across multiple devices, with each device receiving its own values during deployment.

Notes & Best Practices

1. Order of operations matters:

   • Create Feature Profiles & Parcels before creating the Configuration Group
   • Associate devices before assigning variables
   • Assign variables before deploying

2. Idempotent reads: All GET operations are safe to retry and can be used for polling.

3. Full PUT updates: When editing a group, send the complete object — partial updates are not supported.

4. Variable completeness: Deployment will fail if required device variables are not assigned. Use the fetch endpoint (5.10.1) to discover all required variables.

5. Preview before deploy: Always preview at least one device’s config to catch errors before pushing to production.

6. Topology Groups are fabric-wide: They don’t need per-device association — they apply based on tag-based criteria.

7. Deactivation vs. Deletion: For Topology Groups, you can deactivate the topology (remove overlay) without deleting the group definition. This is useful for troubleshooting.