CX as Code CLI failing to export all Architect flows

General Discussion
1

I’ve spent hours trying to figure out why the CX as Code CLI only exports a subset of flows despite using the --all flag. My environment is configured as follows:

  • CLI version: 2.1.4
  • Auth: Service account with Organization Admin role
  • Command: genesys cloud export --all --path ./flows

The JSON output is missing flows created in the last 48 hours. Is there a caching issue or a specific filter I need to bypass in the export configuration?

2

Make sure you clear the local CLI cache using genesys cloud cache clear before re-running the export, as stale metadata often causes this lag. See the workaround in this internal note: https://support.zapier.com/hc/en-us/articles/cx-code-cli-cache-fix

3 Likes
3

TL;DR: Cache clear didn’t fix it. Check division IDs and flow status filters in your CLI config.

Make sure you aren’t assuming --all bypasses division scoping. The CLI respects the --division-id or default division context unless explicitly overridden. If those new flows were created in a different division than your service account’s default, they won’t show up even with --all.

Also, verify the flow status. By default, the export might skip DRAFT or INACTIVE flows depending on your version’s default filters. You can force inclusion by adding --include-status DRAFT,INACTIVE,ACTIVE if your CLI version supports it (check genesys cloud export --help).

Here is how I handle this in my Deno Deploy functions when I need to ensure I’m pulling the right data directly from the API, bypassing CLI quirks entirely:

// Deno Deploy example to fetch flows with explicit division and status
const response = await fetch(
 `https://${env.SUBDOMAIN}.mygenesys.com/api/v2/architect/flows?divisionId=${env.DIVISION_ID}&pageSize=100`,
 {
 headers: {
 "Authorization": `Bearer ${env.ACCESS_TOKEN}`,
 "Accept": "application/json"
 }
 }
);

const data = await response.json();
// Check data.entities.length vs data.pageCount to handle pagination
// Ensure you filter by status if needed: data.entities.filter(f => f.status === 'ACTIVE')

If you stick with CLI, try running it with --trace to see the exact API calls being made. You’ll likely see the divisionId parameter is restricted. Clearing the cache (as suggested above) helps with metadata staleness, but it won’t fix a scope mismatch.

Also, double-check that your service account actually has Architect:Flow:Read permissions in that specific division. Organization Admin role doesn’t always grant implicit access to all divisions if they are strictly scoped.

4

This is actually a known issue…

The CLI defaults to the primary division. New flows in secondary divisions require explicit handling. Verify scope via API directly:

curl -H "Authorization: Bearer $TOKEN" "https://api.mypurecloud.com/api/v2/architect/flows?status=published&divisionId=/api/v2/divisions/{id}"

See Flows API docs for pagination limits.

1 Like