Cisco Workflows - Configure a UX 2.0 device

This guide provides an importable Cisco Workflows definition that follows the same UX 2.0 sequence as this configuration guide and the Bruno collection. The workflow creates feature profiles and parcels, groups them into a configuration group, associates one device, assigns device variables, and deploys the configuration.

Download and import

Download configure-router.json and import it from the Workflows page using Import Workflows → JSON → Files. Choose the downloaded JSON file; do not use a browser URL for the local path.

The short filename is only a local convenience—the opaque workflow.unique_name inside the JSON is unchanged. A Git-backed import that expects native export packaging may instead require a directory named <display-name>__<workflow_unique_name> containing <workflow_unique_name>.json.

Because this definition deliberately reuses the object-ID format from the known-good exported workflow, enable Import as a new workflow (duplicate) in the import dialog. Do not import it as an overwrite of the existing Unified Branch with Meraki SD-WAN - Small workflow.

The SD-WAN Manager target definition is embedded in the workflow export; no separate target file is required. It uses the reserved placeholder host sdwan-manager.example.com. After import, replace that value with the SD-WAN Manager host and verify the port and HTTPS settings. Configure the target’s default account key as HTTP Bearer Authentication before running the workflow.

The real API key must be entered in the Workflows target and must not be committed to this repository. The exported APIKEY runtime-user value is masked as *****; it is not a usable credential.

Workflow sequence

The workflow executes this sequence:

target Bearer key -> XSRF token -> four parallel profile branches
                  -> configuration group -> associate device
                  -> fetch/set variables -> deploy -> poll status

All parallel blocks use continue_on_failure: false. The configuration-group request therefore runs only after every profile branch completes successfully.

Connection and authentication

The workflow uses API-key-only authentication through an existing HTTP Endpoint target whose default account key type is HTTP Bearer Authentication. It first calls GET /dataservice/client/token; Workflows supplies the target’s Bearer key automatically, and the request sends Content-Type: application/json without a restrictive Accept header. The response is sent as X-XSRF-TOKEN on subsequent requests. No SD-WAN Manager username or password is required for API authentication.

Scope

The workflow exposes example defaults for the following run-wizard inputs:

• Device AAA password
• Device UUID
• Hostname, system IP, site ID, and pseudo commit timer
• INET, MPLS, and LAN interface IP addresses
• DHCP network, excluded address, and default gateway

It creates the system, transport, service, and CLI feature profiles and their parcels, creates the configuration group, associates the supplied device UUID, assigns device variables, deploys the group, and polls /dataservice/device/action/status/{parentTaskId}.

Outputs and safety

The workflow produces these outputs during execution:

• Configuration group ID
• Deployment parent task ID
• Deployment status

It assigns the documented device variables through the configuration-group device-variable API and keeps global parcel values in the relevant parcel payloads.

The workflow creates named objects beginning with WF_edge_ and deploys to the supplied device. It does not delete or clean up objects. Review the target, device UUID, payload defaults, and API-key permissions before running it. A second run can fail if the same profile or configuration-group names already exist; cleanup remains a separate, explicitly authorized operation.

The workflow has not been run against a live Manager during validation. Validate the imported workflow in the Workflows editor before execution, and review the target endpoint before publishing or sharing the JSON.