Cisco Workflows + IOS-XE: A Hands-On Walkthrough for Running CLI on Catalyst Devices

In the previous posts we covered what Cisco Workflows is and why it matters, and walked through seven real use cases — branch provisioning, RMA automation, ISE integration, and so on. This post zooms in on one of the most common operational tasks you’ll want to automate: running commands on an IOS-XE Catalyst device and doing something with the output.

This is the bridge that turns Workflows from a “Meraki Dashboard automation tool” into a true cross-domain orchestration engine. Once you can drive a Catalyst switch from a workflow, you can stitch IOS-XE devices into the same automations as Meraki networks, ISE policy changes, and ServiceNow tickets — all from a no-code visual designer.

What we’ll build: a workflow that takes a switch IP and a list of show commands as inputs, connects to the switch over SSH, executes the commands, captures the output, and returns the result. Once that pattern is in place, everything else — config pushes, conditional remediation, AI-assisted troubleshooting — is just adding nodes to the same diagram.

Three paths to drive IOS-XE from Workflows

Before we open the editor, it’s worth knowing the three integration paths and why I’m picking SSH for this walkthrough.

1. Catalyst Center adapter. If you have Cisco Catalyst Center (formerly DNA Center) managing your IOS-XE fleet, Workflows has hundreds of pre-built activities that target Catalyst Center’s APIs — inventory queries, command runner, template deployment, image upgrades. This is the most “managed” path. Use it when Catalyst Center is your source of truth.

2. Meraki Dashboard adapter (for cloud-managed Catalyst). If your IOS-XE switches are Meraki-managed Catalyst — the C9300-M, 9300X-M, 9300L-M, MS390, or any Catalyst 9000 onboarded with cloud configuration — then the Meraki atomics already cover most port, VLAN, and configuration tasks via the Meraki API. CLI access on these devices is via Cloud CLI, which is interactive and not directly automatable from Workflows yet.

3. SSH adapter (this walkthrough). A generic SSH target works with any IOS-XE device — traditional CLI-managed Catalyst that isn’t onboarded to anything yet, branch routers, ISR/ASR boxes, IE3500 industrial switches, lab gear. It’s the most universal path and the one that translates closest to “I would have SSH’d in and typed this.” That’s what we’re building here.

If you have Catalyst Center and want a deeper governed integration, swap the SSH activity in this walkthrough for the matching Catalyst Center “Run command” activity. The rest of the workflow logic is identical.

Prerequisites

• A Meraki Dashboard account. Workflows is included with any Cisco network management license — you don’t need to be paying for Meraki hardware. If you don’t have one, create a free account at account.meraki.com.
• An IOS-XE device you can reach. For a first run, a lab VM (CML, EVE-NG, or a real C9000) is ideal. You’ll need its IP, an SSH-enabled VTY, and a privilege-15 (or sufficient) local user.
• Network reachability from Workflows to the device. Workflows runs in the Meraki cloud, so the device must be reachable from the internet or you’ll need the Automation Remote agent (covered briefly below). For a public-IP lab device, allowlist the Workflows source IP ranges — find them at Help → Support → Firewall Info inside the Meraki Dashboard.
• About 15 minutes.

Step 1 — Open the Workflows workspace

In the Meraki Dashboard sidebar, click Automation. You’ll land on the Workspace by default, which has its own tabs: Workflows, Atomics, Recently Run, and Favorites. Across the Automation menu you’ll find:

• Workspace — where you build, browse, and run workflows (tabbed inside as above).
• Exchange — the library of pre-built, Cisco-validated workflows you can fork.
• Targets — connections to systems your workflows talk to. This page is where both Remote Targets and Account Keys now live as sub-tabs (they moved here in mid-2025; older docs and screenshots may show them as separate menu items).
• Variables — named values you reuse across runs.
• Rules and User Tasks — triggers, and the pending-approval queue for human-in-the-loop steps.

We’ll touch four of these before we’re done: Account Keys, Targets, Workspace, and a brief look at Tasks.

Step 2 — Store the device credentials in an Account Key

Don’t paste a username and password into the activity directly. Workflows has a first-class secrets store called Account Keys — every secret reference in a workflow points at an Account Key by name, so when you rotate the credential there’s exactly one place to update.

1. Go to Automation → Targets and switch to the Account Keys tab.
2. Click New Account Key.
3. From the Account Key Type dropdown, choose Terminal Password-Based Credentials (for username/password SSH or Telnet) or Terminal Public Key Credentials (for SSH key-based auth — recommended for anything beyond a lab).
4. Give it a clear name. I use the pattern ssh-<device-class>-<env>, so for this walkthrough: ssh-iosxe-lab.
5. Enter the username and password (or paste a private key for the public-key variant). Optionally fill in the Admin Password field for the IOS-XE enable secret if you’ll need to drop into privileged mode.
6. Save.

The key is now referable by name and never exposed in the workflow JSON. An organization can have up to 300 Account Keys total, which is far more than most teams will use — but consolidating shared credentials (one key per role rather than per device) keeps things manageable.

Step 3 — Create a Target for the IOS-XE device

A Target is a logical connection. It pairs a network endpoint (IP/hostname/port) with an Account Key.

1. Go to Automation → Targets (Targets tab).
2. Click New Target.
3. From the Target Type dropdown, choose Unix/Linux Endpoint (also referred to as a Terminal Endpoint in some places — same thing). This is the generic SSH/Telnet target type, and it works fine against IOS-XE devices.
4. Give it a specific name: iosxe-lab-switch-01. Resist the temptation to make a generic ssh-target — once you have ten devices, names matter.
5. Fill in the host (IP or DNS), port (22 for SSH), and select the Account Key you created in Step 2 from the Default Account Keys dropdown.
6. Optional: configure host-key handling. Strongly recommended for production; safe to skip on a lab box.
7. Save and use the test connection feature to confirm Workflows can reach the device.

If the test fails, the usual suspects are:

• Source IPs not allowlisted on the device or upstream firewall (check Workflows source IPs again).
• VTY transport not set to SSH (line vty 0 4 / transport input ssh).
• AAA misconfig — make sure the local username or AAA method the device falls back to actually works.

Step 4 — Build the workflow

Back to Workspace → Create Workflow → Blank. Name it iosxe-show-runner or similar.

The editor is drag-and-drop. You’ll see the Activities panel on the left, grouped by source (Meraki, Catalyst Center, SSH, ISE, REST, control flow like If/Loop/Wait). The canvas is in the middle. The properties panel is on the right.

4a — Define inputs

Workflows can take inputs at run time so the same workflow handles “switch A with command set 1” and “switch B with command set 2” without duplication.

1. Click the workflow’s Inputs in the right-hand panel.
2. Add two inputs:
   • target_name (String) — the name of the SSH Target to run against. Default to your Target name.
   • commands (List of String) — the show commands you want to run, one per list item. Default to something like ["show version", "show interfaces status", "show ip interface brief"].

Inputs become available as variables you can drag into any activity downstream.

4b — Add the terminal command activity

1. From the Activities panel, expand the Terminal (Unix/Linux) atomics and find the activity that executes a command on a Terminal/Unix-Linux endpoint. The exact name varies slightly by OVA/version (Cisco has been actively renaming atomics), but it’s the one whose description says “execute a command on a Unix/Linux/Terminal endpoint.”
2. Drag it onto the canvas immediately after Start.
3. In its properties:
   • Target → bind to inputs.target_name (or hard-code to your Target name for a first test).
   • Command / Commands → bind to inputs.commands. Some variants of the atomic take a single command; iterate with a Loop block if so.
   • Timeout → 60 seconds is fine for show commands; bump for slow commands like show tech-support.
4. Save.

The activity will SSH into the device, send each command in sequence, capture stdout per command, and emit a structured result.

4c — Capture the output to a variable

The terminal activity already exposes its output as a downstream variable (<activity-name>.output), but it’s good practice to assign it to a named workflow variable for clarity.

1. Add a Set Variable activity after the SSH step.
2. Name the variable command_results.
3. Value: bind to the SSH activity’s output object.

Now anything downstream can reference command_results.commands[0].stdout for the first command’s output.

4d — Do something with the output

This is where the workflow earns its keep. A few common patterns:

Just return it. Add an End node and set the workflow’s output to command_results. Now anyone who runs the workflow — manually, via AI Assistant, or via webhook — gets the structured output in the response. This is the “remote show button” pattern: useful for help-desk staff who shouldn’t have SSH access but need to read a device.

Email it. Drag in the Send Email activity. Bind the body to a JSON-stringified command_results. Triggered by a schedule (daily 7am compliance check) or webhook (alert fires → workflow grabs state → emails NetOps).

Parse and branch. Drag in a JavaScript activity (or use an If-condition). Inspect command_results.commands[0].stdout for a regex match — say, lines starting with Eth and ending in notconnect. If a match exists, flag the port. Then a downstream activity can send a Slack notification or open a ServiceNow ticket.

Push a fix. Add a second terminal-command activity in config mode. Set its commands to a list like ["conf t", "interface Gi1/0/12", "shutdown", "no shutdown", "end", "write"]. Wrap it behind a Request Approval task so a human signs off before the change executes — a one-checkbox addition that turns this into a safe, governed remediation workflow.

Step 5 — Test the workflow

Hit the Run button at the top of the editor. Workflows will prompt for any inputs you defined (target name, commands). Fill them in, hit Run.

The execution view shows each node lighting up green (success), yellow (running), or red (failed). Click any node to inspect the inputs and outputs at that step — this is your debugger. Output blobs are pretty-printed; the SSH activity shows the raw text of each command’s response so you can see exactly what came back from the device.

Common first-run failures:

• “Authentication failed.” — Wrong Account Key bound, or the device’s AAA list rejected the credential. SSH directly from your laptop with the same creds to confirm.
• “Connection timed out.” — Firewall, Workflows source IP not allowed, or device VTY ACL too restrictive.
• “Command timeout.” — Long-running commands like show tech-support need a higher timeout. Bump from 60s to 300s, or break the request into multiple smaller commands.
• “Unexpected prompt.” — Device dropped into a paginator prompt because terminal length wasn’t set. Add terminal length 0 as the first command in your list.

That last one bites everyone the first time. The fix is mechanical: every IOS-XE workflow should set terminal length 0 as command #1.

Step 6 — Promote, save, share

Once the workflow runs cleanly:

1. Save it. Workflows version automatically; you can roll back from the version dropdown.
2. Add triggers. Under the workflow’s properties, you can enable any of: manual run, schedule, webhook (Workflows generates the URL and auth), or AI Assistant. Enabling AI Assistant exposes the workflow’s purpose + inputs to Cisco’s AI Assistant, so anyone can run it via natural language (“run the daily compliance check on iosxe-lab-switch-01”).
3. Export it. Workflows can be exported as portable JSON and re-imported in another organization — the way you ship automations between dev/test/prod environments.

Best practices once you start building real workflows

A few things I’ve learned by breaking workflows on real gear:

Always start in monitor mode. First run: show commands only. Second run: show + a Request Approval step. Third run: real config. The mistake is going straight to config pushes on day one.

Use the Account Key store; never inline secrets. Inline credentials end up in workflow exports, AI Assistant outputs, and run logs. Every Workflow secret should be an Account Key reference.

Pin a host-key fingerprint on production targets. Without host-key verification, a man-in-the-middle could swap in a malicious endpoint and harvest credentials. The pin takes 30 seconds to add and turns SSH into mutual auth.

Set terminal length 0 as command 1. Always. Otherwise pagination prompts will break long outputs.

Cap timeouts on a per-command basis. show tech-support and show running-config on a large box can blow 60s. Set realistic upper bounds so failed commands don’t hang the whole workflow.

Don’t expose destructive workflows to the AI Assistant until you’ve gated them with Request Approval. The pattern is: AI Assistant can call the workflow → workflow generates a “human, please confirm” task → human approves in the dashboard → workflow proceeds. Without that step, “delete vlan 100 on every switch in Chicago” is one prompt away.

Tag and name workflows aggressively. Workspaces fill up fast. Use a prefix pattern (iosxe-, meraki-, dc-, compliance-) and a one-line description per workflow so the next engineer can find what they need.

What about the Automation Remote?

If your IOS-XE devices live on a private network that the Workflows cloud can’t reach, the Automation Remote is a small on-prem virtual appliance (VMware OVA) that registers with Workflows and acts as a relay. Your SSH activity targets the device through the Remote, so the device never needs an internet-facing path. This is the deployment model for most enterprise networks — public-internet SSH to production gear is rarely a good idea anyway.

The Remote install has its own walkthrough — see Cisco Workflows Automation Remote: OVA Deployment Walkthrough — but the takeaway is: don’t let a private-network constraint stop you from automating. The Remote exists precisely for this case.

TL;DR

• Workflows can drive IOS-XE three ways: Catalyst Center adapter (managed, governed), Meraki API for cloud-managed Catalyst (limited to dashboard-supported operations), or the SSH adapter (universal, works on any IOS-XE).
• The pattern is: Account Key → Target → Workflow → Terminal command activity → act on output. Five components, all reusable.
• For a first walkthrough, build a show-only workflow with inputs for the target and command list. Once that works, layering on Request Approval, config pushes, and AI Assistant integration is just additional nodes.
• The five habits worth forming on day one: store secrets in Account Keys, pin host-key fingerprints, send terminal length 0 first, gate destructive ops behind approval, and tag workflows so future-you can find them.

This is the bridge post for the series — from here, every Meraki Workflow pattern you’ve seen (RMA automation, branch provisioning, ISE policy changes) becomes available against IOS-XE devices too. Combine that with the Claude IOS-XE automation patterns and you have natural-language → governed-workflow → real-config-on-real-gear, end to end.

Reference: Cisco Workflows documentation.