Imported from achobgood/wxops (src/wxcli/_playbook/.codex/skills/contact-center/SKILL.md). Install upstream with npx skills add achobgood/wxops --skill contact-center. Copyright stays with the author.

Contact Center Workflow

Checkpoint — do NOT proceed until you can answer these:

1. What CLI command sets the CC API region? (Answer: wxcli set-cc-region <region> — defaults to us1. Valid regions: us1, eu1, eu2, anz1, ca1, jp1, sg1.)
2. What base URL do CC API calls target? (Answer: api.wxcc-{region}.cisco.com, not webexapis.com.)
3. How do you verify CC auth is working? (Answer: wxcli whoami for token, then wxcli cc-site list -o json to confirm CC access.)

If you cannot answer all three, you skipped reading this skill. Go back and read it.

Step 1: Load references

1. Read docs/reference/contact-center-core.md for agents, queues, entry points, teams, skills, desktop profiles, sites, aux codes, and configuration data models
2. Read docs/reference/contact-center-routing.md for dial plans, campaigns, flows, audio files, contacts, outdial ANI
3. Read docs/reference/contact-center-analytics.md for AI features, monitoring, subscriptions, tasks
4. Read docs/reference/contact-center-journey.md for JDS: workspaces, persons, identity, profile views, events, WXCC subscription

Out of scope for this skill: if the user wants to build a custom agent desktop (a browser softphone on the @webex/contact-center JS SDK — webex.cc, task.*, WebRTC audio), that is not a wxcli task and this skill has no path for it. Send them to docs/reference/contact-center-agent-sdk.md. This skill provisions the agents, queues and profiles such a desktop connects to — including loginVoiceOptions on the desktop profile, which is the gate on browser audio.

Mandatory --help verification: Before constructing any wxcli command, run wxcli <group> --help to verify the subcommand exists, then wxcli <group> <subcommand> --help to verify the exact flags (e.g. wxcli cc-queue create --help — note the cc- prefix is what distinguishes Contact Center commands from Calling, so cc-queue ≠ call-queue; guessing the wrong one builds the wrong entity). Do NOT rely on examples in this skill or reference docs — the CLI is auto-generated and flag names may differ from what documentation suggests.

Step 2: Verify auth token and CC region

Before any API calls, confirm the user has a working auth token and CC region is configured:

wxcli whoami

If this fails, stop and resolve authentication first (wxcli configure).

Set CC region

CC commands target api.wxcc-{region}.cisco.com. The region must be set before any cc-* command:

wxcli set-cc-region us1

Valid regions: us1, eu1, eu2, anz1, ca1, jp1, sg1.

Verify CC access

After setting the region, confirm the token has CC admin access:

wxcli cc-site list -o json

If this returns 403, the token lacks CC-specific OAuth scopes. Required scopes:

• Read: cjp:config_read
• Write: cjp:config_write
• JDS admin (Journey Data Service): cjds:admin_org_read and/or cjds:admin_org_write — required for /admin/v1/api/... JDS endpoints (workspace, person, template management). Standard cjp: scopes alone will not grant JDS admin access.

The user may need to re-authenticate with CC scopes enabled.

WARNING: Personal access tokens (PATs) from developer.webex.com do NOT carry CC scopes, even for full admins. If you get 403 "Access denied - Client is forbidden access to the resource" with a ccconfig_ tracking ID, the token lacks CC scopes. Two options:

Option A — OAuth Integration (user-facing apps):

1. Create an OAuth integration at developer.webex.com with cjp:config_read and cjp:config_write scopes selected
2. Complete the OAuth authorization flow to get a token
3. Run wxcli configure with the new token
4. If you added scopes to an existing integration, you must re-authorize — old tokens don't pick up new scopes

Option B — Service App (production automation, no interactive login):

1. Create a Service App at developer.webex.com with cjp:config_read and cjp:config_write scopes (all CC scopes work except spark:applications_token and spark:kms)
2. Have a Full Admin authorize the app in Control Hub → Management → Apps → Service Apps
3. Generate tokens in the developer portal (Access Token: 14-day, Refresh Token: 90-day)
4. Run wxcli configure with the access token

Note: The CC API requires the bare UUID org ID (e.g., a9527d60-...), not the base64-encoded Spark ID (Y2lzY29...). The CLI handles this automatically via get_cc_org_id(), which decodes the Spark ID to extract the UUID. No manual conversion is needed.

Step 3: Identify the operation

Ask the user what they want to configure. Present this decision matrix if they are unsure:

Agent Management

Queue & Routing

Campaign & Contacts

Configuration

Flows & Automation

AI & Analytics

Monitoring & Events

Not Contact Center?

Step 4: Check prerequisites

Before creating any CC resource, verify these conditions:

4a. CC tenant is provisioned

The org must have Webex Contact Center provisioned. Confirm with:

wxcli cc-site list -o json

If this returns empty or errors, the CC tenant is not provisioned. The user must provision CC through Control Hub first.

4b. At least one site exists

Most CC resources are site-scoped. Confirm a site exists:

wxcli cc-site list -o json

If no sites exist, create one first:

wxcli cc-site create --json-body '{
  "name": "Main Site",
  "multimediaProfileId": "PROFILE_ID"
}'

4c. Resource-specific prerequisites

Queues

Teams

Campaigns

Flows

Skill Profiles

Desktop Profiles

Event Subscriptions

Step 5: Gather configuration and present deployment plan -- [SHOW BEFORE EXECUTING]

Based on the selected operation, collect the required parameters from the user. Always present the plan before executing.

Queue (Contact Service Queue)

Collect from user:

CLI command (v2 — preferred):

wxcli cc-queue create --json-body '{
  "name": "Support Queue",
  "channelType": "telephony",
  "routingType": "LONGEST_AVAILABLE_AGENT"
}'

List queues:

wxcli cc-queue list-contact-service-queue-v2 -o json

Show specific queue:

wxcli cc-queue show-contact-service-queue-v2 QUEUE_ID -o json

Queue Skill-Based Routing Queries

These commands query queues based on skill, team, or user assignments. Useful for verifying routing configuration and debugging skill-based queue assignments.

List queues assigned to a specific team:

wxcli cc-queue list-team-based-queues TEAM_ID -o json

List queues for a CI user:

wxcli cc-queue list-agent-based-queues USER_CI_ID -o json

List skill-based queues by CI user:

wxcli cc-queue list-agent-based-queues USER_CI_ID -o json

List queues by skill profile:

wxcli cc-queue list-skill-based-queues SKILL_PROFILE_ID -o json

Fetch queues by dynamic skill and skill profile (POST):

wxcli cc-queue create-fetch-by-dynamic-skills-and-skill-profile --json-body '{
  "dynamicSkillIds": ["SKILL_ID"],
  "skillProfileId": "SKILL_PROFILE_ID"
}'

Fetch queues by user ID and skill profile ID (POST):

wxcli cc-queue create-fetch-by-user-id-skill-profile-id --json-body '{
  "userId": "USER_ID",
  "skillProfileId": "SKILL_PROFILE_ID"
}'

Fetch queues by grouped assistant skill (v2, POST):

wxcli cc-queue create-fetch-by-grouped-assistant-skill --json-body '{
  "skillIds": ["SKILL_ID"]
}'

Entry Point

Collect from user:

CLI command (v2 — preferred):

wxcli cc-entry-point create --json-body '{
  "name": "Main IVR",
  "channelType": "telephony"
}'

List entry points:

wxcli cc-entry-point list-entry-point -o json

Show specific entry point:

wxcli cc-entry-point show ENTRY_POINT_ID -o json

Team

Collect from user:

CLI command:

wxcli cc-team create --json-body '{
  "name": "Support Team",
  "siteId": "SITE_ID",
  "multimediaProfileId": "MM_PROFILE_ID"
}'

List teams:

wxcli cc-team list -o json

Show specific team:

wxcli cc-team show TEAM_ID -o json

CC Users

This is the agent roster. If someone asks to "list the agents", this is the command — not anything under cc-agents, which holds only runtime session and telemetry operations. Verified live 2026-07-29: each record carries firstName, lastName, email, ciUserId, contactCenterEnabled, siteId, teamIds, agentProfileId, skillProfileId. Use list-with-user-profile when you also need each user's profile permissions expanded inline instead of a bare userProfileId.

List CC users (the agent roster):

wxcli cc-users list -o json

List the roster with profile permissions expanded:

wxcli cc-users list-with-user-profile -o json

Show a CC user:

wxcli cc-users show USER_ID -o json

Bulk update dynamic skill for users:

wxcli cc-users update-dynamic-skill --json-body '{
  "userIds": ["USER_ID_1", "USER_ID_2"],
  "dynamicSkillId": "SKILL_ID",
  "skillValue": 8
}'

List users with a specific dynamic skill:

wxcli cc-users show-by-dynamic-skill-id DYNAMIC_SKILL_ID -o json

Reassign skill profiles to a user (reskill):

wxcli cc-users update-reskill USER_ID --json-body '{
  "skillProfileId": "NEW_SKILL_PROFILE_ID"
}'

Skill & Skill Profile

Create a skill definition:

wxcli cc-skill create --json-body '{
  "name": "Spanish",
  "skillType": "PROFICIENCY",
  "description": "Spanish language proficiency"
}'

Skill types: PROFICIENCY (1-10 scale), BOOLEAN (true/false), TEXT (string match), ENUM (set of values).

List skills:

wxcli cc-skill list-skill -o json

Create a skill profile:

wxcli cc-skill-profile create --json-body '{
  "name": "Bilingual Agent",
  "description": "English + Spanish",
  "skills": [
    {"skillId": "SKILL_ID", "skillValue": 8}
  ]
}'

List skill profiles:

wxcli cc-skill-profile list-skill-profile -o json

Dial Plan & Dial Number

Create a dial plan:

wxcli cc-dial-plan create --json-body '{
  "name": "US Dial Plan",
  "description": "US domestic dialing rules"
}'

List dial plans:

wxcli cc-dial-plan list-dial-plan -o json

NOTE: cc-dial-plan list is a references endpoint (shows what references a specific dial plan), not a list-all. Always use list-dial-plan-v2 to list all dial plans.

Map a dial number to an entry point:

wxcli cc-dial-number create --json-body '{
  "dialNumber": "+18005551234",
  "entryPointId": "ENTRY_POINT_ID"
}'

Campaign Group Lookup

cc-campaign-group list looks up campaigns by campaign group name. There is no CLI command to enumerate campaign group names themselves — get the name from Control Hub or wherever the campaign group was created.

wxcli cc-campaign-group list CAMPAIGN_GROUP_NAME -o json

Takes one required argument, CAMPAIGN_GROUP_NAME. Optional --page, --page-size (1-100), and --campaign-status (Draft, Running, Pending, Paused, Completed, Ended) filter/paginate the result.

The response is {"outcome", "statusCode", "pagination", "campaigns": [...]}; the CLI extracts campaigns. Each campaign carries campaignId, campaignName, status, campaignDialingMode, campaignType, channel, outdialANI, scheduleInfo and more — note there is no id or name field, so project on the real names: --fields '[].{id:campaignId,name:campaignName}'.

Verified live: an unknown or nonexistent campaign group name does not 404 — the API returns 500 {"code":"InternalServerError","message":"An unexpected error occurred"} after the CLI's automatic retry. A 500 here means the group name is wrong, not that the CLI is broken.

Business Hours & Holidays

Create business hours:

wxcli cc-business-hour create --json-body '{
  "name": "Standard Hours",
  "timezone": "America/New_York",
  "businessHours": [
    {"day": "monday", "startTime": "08:00", "endTime": "17:00"},
    {"day": "tuesday", "startTime": "08:00", "endTime": "17:00"},
    {"day": "wednesday", "startTime": "08:00", "endTime": "17:00"},
    {"day": "thursday", "startTime": "08:00", "endTime": "17:00"},
    {"day": "friday", "startTime": "08:00", "endTime": "17:00"}
  ]
}'

List business hours:

wxcli cc-business-hour list -o json

Create a holiday list:

wxcli cc-holiday-list create --json-body '{
  "name": "US Holidays 2026",
  "holidays": [
    {"name": "New Year", "startDate": "2026-01-01", "endDate": "2026-01-01"},
    {"name": "Memorial Day", "startDate": "2026-05-25", "endDate": "2026-05-25"}
  ]
}'

Desktop Layout & Desktop Profile

Create a desktop layout:

wxcli cc-desktop-layout create --json-body '{
  "name": "Standard Layout",
  "description": "Default agent desktop"
}'

List desktop layouts:

wxcli cc-desktop-layout list-desktop-layout -o json

Create a desktop profile:

wxcli cc-desktop-profile create --json-body '{
  "name": "Standard Profile",
  "desktopLayoutId": "LAYOUT_ID"
}'

List desktop profiles:

wxcli cc-desktop-profile list-agent-profile -o json

Multimedia Profile

Create a multimedia profile:

wxcli cc-multimedia-profile create --json-body '{
  "name": "Voice Only",
  "mediaTypes": [
    {"media": "telephony", "maxCount": 1}
  ]
}'

List multimedia profiles:

wxcli cc-multimedia-profile list-multimedia-profile -o json

Channels & Assets

A channel is the medium a contact arrives on; an asset is one configured instance of a channel. Create the channel first — an asset must name an existing channelId. Neither group is prefixed cc-: they register as channel and asset.

List channels and assets:

wxcli channel list-channel --all --fields '[].{id:id,name:name}' -o json
wxcli asset list-asset --all --include-channel-name true -o json

Create a channel — create is the BULK endpoint, so the body needs an items array:

wxcli channel create --json-body '{"items":[{"requestAction":"CREATE","name":"Web Chat","description":"Public website chat","channelType":"CHAT"}]}'

Create an asset against that channel:

wxcli asset create --name "Tier 2 Work Items" --channel-type WORK_ITEM --channel-id CHANNEL_ID --business-address "600 Congress Ave, Austin TX"

Before changing or deleting either, check what references it:

wxcli channel list-incoming-references CHANNEL_ID
wxcli asset list-incoming-references ASSET_ID

Two traps, both in docs/reference/contact-center-routing.md §§ 15-16: asset update (PUT) is for WORK_ITEM assets and asset update-asset (PATCH) is for CUSTOM_MESSAGING assets — the wrong one is a 4xx, so check channelType with asset show first. And single channel create / full channel update are multipart (logo upload) and have no CLI command; use raw HTTP for those.

Aux Codes & Work Types

Create an aux code (idle/wrap-up code):

wxcli cc-aux-code create --json-body '{
  "name": "Break",
  "description": "Agent on break",
  "isSystemCode": false
}'

List aux codes:

wxcli cc-aux-code list-auxiliary-code -o json

Create a work type:

wxcli cc-work-types create --json-body '{
  "name": "Follow-up Call",
  "description": "Post-call follow-up"
}'

List work types:

wxcli cc-work-types list-work-type -o json

Global Variables

Create a global variable:

wxcli cc-global-vars create --json-body '{
  "name": "maxRetries",
  "variableType": "INTEGER",
  "defaultValue": "3",
  "description": "Max IVR retry attempts"
}'

Variable types: STRING, INTEGER, BOOLEAN, DECIMAL, DATE_TIME, JSON.

List global variables:

wxcli cc-global-vars list-cad-variable -o json

Flow Management

List flows:

wxcli cc-flow list PROJECT_ID -o json

Export a flow:

wxcli cc-flow export FLOW_ID PROJECT_ID -o json

Use --version to specify a version: draft, latest, or a specific version ID.

wxcli cc-flow export FLOW_ID PROJECT_ID --version draft -o json

Publish a flow:

wxcli cc-flow publish FLOW_ID PROJECT_ID --comment "Initial publish"

Use --json-body for additional publish options (e.g., tag IDs):

wxcli cc-flow publish FLOW_ID PROJECT_ID --json-body '{
  "comment": "Production release",
  "tagIds": ["TAG_ID"]
}'

NOTE: Flow import (file upload) is not available via CLI. Use Control Hub or the API directly for flow import.

JDS (Journey Data Service) — Flow Designer Integration

JDS tracks customer journey events. The two most common flow patterns are:

1. Detect returning caller at flow entry

Query JDS by CallerANI at the start of the flow using an HTTP Request node:

Method: GET
URL: https://api.wxcc-{region}.cisco.com/admin/v1/api/person/workspace-id/{{CJDS_Workspace_ID}}/aliases/{{CallerANI}}
Authorization: Bearer {{cc_oauth_token}}

• 200 + data array → caller exists in JDS; check event history to determine if returning
• NOT_FOUND → first-time caller (no prior contacts)
• CallerANI must be E.164 with +1 prefix — WXCC writes ANI that way, so +19105551234, not 9105551234

2. Post a custom event from a flow

Use an HTTP Request node to record a business event (e.g., store verified, order looked up):

Method: POST
URL: https://api.wxcc-{region}.cisco.com/publish/v1/api/event?workspaceId={{CJDS_Workspace_ID}}
Authorization: Bearer {{cc_oauth_token}}
Content-Type: application/json

Body:

{
  "id": "{{DialedDNIS}}-{{CallerANI}}",
  "specversion": "1.0",
  "type": "custom:your_event_type",
  "source": "wxcc_flow",
  "identity": "{{CallerANI}}",
  "identitytype": "phone",
  "datacontenttype": "application/json",
  "data": {
    "event": "your_event_type"
  }
}

workspaceId goes on the query string — the body schema has no workspaceId field. The URL must be a full absolute URL — relative paths return HTTP 500. id must be unique per event (use a combination of flow variables to ensure uniqueness). A successful post returns "Accepted for processing" — JDS ingests asynchronously.

Query events for a person (wxcli):

wxcli cc-journey show-workspace-id-events WORKSPACE_ID --identity "+19105551234" --filter "type=='custom:your_event_type'" -o json

Filter uses RSQL syntax. Omit --filter to return all events for that identity.

SCIM User Lookup from Flow Designer

Use this pattern to look up a Webex user's identity data (e.g. alternate phone number, userName, ID) from within a WxCC flow using HTTP Request nodes.

Authentication: The SCIM API (/identity/scim/) requires identity:people_read scope — separate from spark-admin:people_read. PATs expire after 12 hours. For production use an OAuth Integration or Service App with identity:people_read explicitly selected at developer.webex.com.

Phone number types: work, mobile, fax, work_extension, alternate1, alternate2

Node 1 — Search by alternate1 phone number (DNIS)

Before this node, add a Set Variable node to strip the + from DNIS:

Variable: DNIS
Expression: {{NewContact.DNIS | slice(1)}}

| slice(1) works in WxCC Flow Designer. | replace("+", "%2B") does NOT — + is a regex special character and fails silently. .substring(1) also does not work.

HTTP Request node config:

• Method: GET
• URL: https://webexapis.com/identity/scim/{orgId}/v2/Users
• Header: Authorization: Bearer {token}
• Query param key: filter
• Query param value: phoneNumbers%5Btype%20eq%20%22alternate1%22%20and%20value%20eq%20%22%2B{{DNIS}}%22%5D
• Output variable: StoreUserPersonId ← JSONPath: $.Resources[0].id

Decoded filter: phoneNumbers[type eq "alternate1" and value eq "+19197010928"]

Key syntax rules:

• No space before [ — phoneNumbers[...] not phoneNumbers [...]
• + must be hardcoded as %2B in the filter — the SCIM server decodes bare + as a space, returning zero results
• phoneNumbers.value eq "..." dot notation returns 400 and is not implemented despite being documented

Node 2 — Get full user profile by ID

HTTP Request node config:

• Method: GET
• URL: https://webexapis.com/identity/scim/{orgId}/v2/Users/{{StoreUserPersonId}}
• Header: Authorization: Bearer {token}
• Query param: attributes=id,userName,phoneNumbers (optional — trims response)
• Output variable: StoreExtension ← JSONPath: $.phoneNumbers[?(@.type=='alternate1')].value

Response is the raw user object (no Resources wrapper), so JSONPath starts at $.phoneNumbers not $.Resources[0].phoneNumbers.

The [?(@.type=='alternate1')] filter expression is supported in WxCC Flow Designer's JSONPath parser.

Auto CSAT

Show Auto CSAT configuration:

wxcli cc-auto-csat show-auto-csat AUTO_CSAT_ID -o json

Update Auto CSAT settings:

wxcli cc-auto-csat update AUTO_CSAT_ID --json-body '{...}'

List Auto CSAT entries:

wxcli cc-auto-csat list -o json

List Auto CSAT questions:

wxcli cc-auto-csat list-question AUTO_CSAT_ID -o json

Call Monitoring

Create a monitoring session:

wxcli cc-call-monitoring create --json-body '{
  "taskId": "TASK_ID",
  "agentId": "AGENT_ID"
}'

Barge into a call:

wxcli cc-call-monitoring create-barge-in TASK_ID

List active monitoring sessions:

wxcli cc-call-monitoring list -o json

End a monitoring session:

wxcli cc-call-monitoring create-end TASK_ID

Event Subscriptions

Create a subscription:

wxcli cc-subscriptions create --json-body '{
  "name": "Agent Events",
  "eventTypes": ["AgentStateChange", "TaskRouted"],
  "callbackUrl": "https://example.com/webhook"
}'

List subscriptions:

wxcli cc-subscriptions list -o json

List available event types:

wxcli cc-subscriptions list-event-types-v2 -o json

Task Management

List tasks:

wxcli cc-tasks list --from 1784592000000 -o json

Accept a task:

wxcli cc-tasks create-accept-tasks TASK_ID

Transfer a task:

wxcli cc-tasks create-transfer-tasks TASK_ID --to QUEUE_OR_AGENT_ID --destination-type queue

Wrap up a task:

wxcli cc-tasks create-wrapup TASK_ID --aux-code-id AUX_CODE_ID --wrap-up-reason "Resolved"

Hold/unhold a task:

wxcli cc-tasks create-hold TASK_ID --media-resource-id MEDIA_RESOURCE_ID
wxcli cc-tasks create-unhold TASK_ID --media-resource-id MEDIA_RESOURCE_ID

Deployment Plan Template

Before executing any commands, present the full plan to the user:

DEPLOYMENT PLAN
===============
Resource type: [queue / entry point / team / skill / flow / ...]
Operation:     [create / update / delete]
Region:        [us1 / eu1 / ...]

Configuration:
  Name: [resource_name]
  [Resource-specific settings listed here]

Dependencies:
  ✓ Site exists: [site_name] ([site_id])
  ✓ [Prerequisite 1]: [name] ([id])
  ✓ [Prerequisite 2]: [name] ([id])

Commands to execute:
  wxcli cc-[group] [command] --json-body '{...}'

Proceed? (yes/no)

Wait for user confirmation before executing.

Step 6: Execute via wxcli

Run the command(s) from the approved deployment plan. If the operation requires multiple steps (e.g., create team then assign agents), execute them in order.

Handle errors explicitly:

Generic errors

• 401/403: Token expired or insufficient scopes — run wxcli configure to re-authenticate. CC requires cjp:config_read / cjp:config_write scopes.
• 403 with scope hint: The CLI detects CC 403 errors and prints a scope tip. Follow the guidance.
• 409: Name conflict — ask user for alternate name.
• 400: Validation error — read the error message and fix the parameter.
• 404: Resource not found — verify the ID and region are correct.

CC-specific errors

• Region mismatch: If calls fail with connection errors, verify the region is correct: wxcli set-cc-region <region>. The CC API base URL is api.wxcc-{region}.cisco.com.
• orgId injection: The CLI auto-injects orgId from the authenticated user's org. If operating on a partner-managed org, ensure wxcli configure has the correct org selected.
• v1 vs v2 endpoints: Some CC groups have both v1 (bulk) and v2 (CRUD) endpoints. Prefer v2 commands (e.g., list-contact-service-queue-v2 over list).
• Bulk operations: v1 bulk endpoints (create, list) handle multiple resources at once. Use these for migrations or large-scale provisioning.

Step 7: Verify creation

After execution, fetch the resource back and confirm:

# Queue
wxcli cc-queue show-contact-service-queue-v2 QUEUE_ID -o json

# Entry point
wxcli cc-entry-point show ENTRY_POINT_ID -o json

# Team
wxcli cc-team show TEAM_ID -o json

# Skill
wxcli cc-skill show SKILL_ID -o json

# Skill profile
wxcli cc-skill-profile show SKILL_PROFILE_ID -o json

# Site
wxcli cc-site show SITE_ID -o json

# Dial plan
wxcli cc-dial-plan show DIAL_PLAN_ID -o json

# Business hours
wxcli cc-business-hour show BH_ID -o json

# Desktop profile
wxcli cc-desktop-profile show PROFILE_ID -o json

# Multimedia profile
wxcli cc-multimedia-profile show MM_PROFILE_ID -o json

# Global variable
wxcli cc-global-vars show VAR_ID -o json

# Aux code
wxcli cc-aux-code show AUX_ID -o json

# Subscription
wxcli cc-subscriptions show SUBSCRIPTION_ID -o json

# CC user
wxcli cc-users show USER_ID -o json

# Auto CSAT
wxcli cc-auto-csat show-auto-csat AUTO_CSAT_ID -o json

Step 8: Report results

Present the results:

CC RESOURCE CONFIGURED
======================
Type: [resource_type]
Name: [name]
ID: [resource_id]
Region: [cc_region]

Configuration:
  [Key settings confirmed]

Next steps:
  - [Resource-specific next steps]
  - [e.g., "Assign flow to entry point"]
  - [e.g., "Add agents to team"]
  - [e.g., "Map dial number to entry point"]

Critical Rules

1. Always set CC region first. Before any cc-* command, ensure the region is set: wxcli set-cc-region <region>. CC API calls go to api.wxcc-{region}.cisco.com, not webexapis.com.
2. CC requires separate OAuth scopes. Standard Webex admin tokens don't include CC scopes. The user needs cjp:config_read and cjp:config_write. The CLI detects 403 and prints a scope tip.
3. Always show the deployment plan (Step 5) and wait for user confirmation before executing.
4. Prefer v2 commands over v1. v2 endpoints are CRUD-oriented (single resource). v1 endpoints are bulk-oriented (arrays). For individual creates/updates, use the v2 variant (e.g., create-contact-service-queue-v2, list-entry-point-v2).
5. orgId is auto-injected. The CLI resolves orgId from the authenticated user's org. No need to pass it manually.
6. Most CC creates use --json-body. CC resources have complex nested structures. Use --json-body '{...}' for creates and updates.
7. Dependency order matters. Create resources in this order: sites → skills → skill profiles → multimedia profiles → desktop layouts → desktop profiles → teams → entry points → queues → dial plans → dial numbers → flows.
8. Delete in reverse dependency order. When tearing down: flows → dial numbers → dial plans → queues → entry points → teams → desktop profiles → desktop layouts → multimedia profiles → skill profiles → skills → sites.
9. Bulk operations for migrations. For large-scale provisioning, use the v1 bulk endpoints (cc-team create-bulk, cc-skill create-bulk, cc-site create-bulk). These accept arrays of resources.
10. Audio files must be uploaded before flow references. If a flow references an audio prompt, upload it via cc-audio-files first.
11. Campaign prerequisites are strict. Campaigns require: contact list, outdial ANI, outbound entry point. Verify all three exist before starting a campaign.
12. Task commands are real-time agent operations. cc-tasks commands (accept, hold, transfer, wrapup) operate on live calls. Confirm with the user before executing.
13. Monitoring is supervisor-only. cc-call-monitoring commands require supervisor privileges. The authenticated user must have the CC supervisor role.
14. Journey API is complex. cc-journey has 41 commands across workspaces, templates, persons, identities, and subscriptions. Read docs/reference/contact-center-journey.md before using. Key gotchas: alias lookup is exact after stripping + (no country-code normalization); WXCC writes ANI in E.164 so lookups must use +1 prefix; events are immutable (no delete); event filter uses RSQL syntax (type=='custom:event_name'); Publish API requires workspaceId as a query param not in the body. For posting events from Flow Designer, see docs/reference/contact-center-routing.md gotchas #16–18.
15. Cross-skill handoffs:
    • Webex Calling features (AA, CQ, HG) → configure-features skill
    • Customer Assist (CX Essentials on Calling queues) → customer-assist skill
    • Webex Calling reporting (CDR, queue stats) → reporting skill
    • Person/workspace call settings → manage-call-settings skill
    • Webex Calling routing (trunks, route groups, PSTN) → configure-routing skill (CC dial plans stay in this skill)
    • Location teardown → teardown skill

Common Workflows

Workflow A: Set up a basic inbound voice queue

1. Verify site exists → wxcli cc-site list -o json
2. Create multimedia profile → wxcli cc-multimedia-profile create --json-body '...'
3. Create team → wxcli cc-team create --json-body '...'
4. Create entry point → wxcli cc-entry-point create --json-body '...'
5. Create queue → wxcli cc-queue create --json-body '...'
6. Map dial number → wxcli cc-dial-number create --json-body '...'
7. Create/assign flow → wxcli cc-flow publish FLOW_ID PROJECT_ID --comment "..."
8. Verify end-to-end → list all resources and confirm IDs are linked

Workflow B: Add skill-based routing

1. Create skill definitions → wxcli cc-skill create --json-body '...' (one per skill)
2. Create skill profiles → wxcli cc-skill-profile create --json-body '...'
3. Update queue routing type → wxcli cc-queue update --json-body '{"routingType": "SKILLS_BASED", ...}'
4. Assign skill profiles to teams/agents
5. Verify queue-to-skill mapping → wxcli cc-queue list-skill-based-queues SKILL_PROFILE_ID -o json
6. Verify user queue assignments → wxcli cc-queue list-agent-based-queues USER_CI_ID -o json

Workflow C: Set up outbound campaign

1. Configure outdial ANI → wxcli cc-outdial-ani create --json-body '...'
2. Upload contact list → wxcli cc-contact-list create --json-body '...'
3. Create outbound entry point → wxcli cc-entry-point create --json-body '...'
4. Start campaign → wxcli cc-campaign create --json-body '...'
5. Verify it joined its group → wxcli cc-campaign-group list "GROUP_NAME" -o json

Workflow D: Configure agent monitoring

1. Create event subscription → wxcli cc-subscriptions create --json-body '...'
2. Monitor live calls → wxcli cc-call-monitoring create --json-body '...'
3. Barge in if needed → wxcli cc-call-monitoring create-barge-in --json-body '...'

Workflow E: Reskill agents

1. List current user skill assignments → wxcli cc-users show USER_ID -o json
2. List users by dynamic skill → wxcli cc-users show-by-dynamic-skill-id SKILL_ID -o json
3. Bulk update dynamic skills → wxcli cc-users update-dynamic-skill --json-body '...'
4. Reassign skill profile → wxcli cc-users update-reskill --json-body '...'
5. Verify updated queues → wxcli cc-queue list-agent-based-queues USER_CI_ID -o json

Context Compaction Recovery

If context compacts mid-execution, recover by:

1. Read the deployment plan from conversation history to recover what was planned
2. Check what's already been created: run the relevant list commands for each resource type
3. Resume from the first incomplete step