Terraform import of GC org config fails on dependency graph

General Discussion
1

What’s the correct sequence to import a full org config using the genesyscloud provider without hitting circular dependency errors? We’re trying to export everything for DR testing but terraform plan keeps choking on the routing queue → skill group → user assignment loop.

  • Provider: genesyscloud v1.45.0
  • Target: Full org export via terraform import
  • Error: Error: Cycle: genesyscloud_routing_queue.main, genesyscloud_routing_skill_group.main

The docs don’t mention a specific import order.

2

The cycle you’re hitting is a classic state file mess. The genesyscloud provider doesn’t handle circular references well during import because it tries to resolve dependencies in a linear pass. Routing queues need skill groups, which might need users, which might be assigned to other queues. It’s a mess.

You can’t just terraform import everything in one go. You need to break the graph. Start with the leaf nodes-things that don’t depend on anything else. Skills, skill groups, and users first. Then move up to routing queues.

Here’s a safer sequence using terraform import:

# 1. Import Skills (no dependencies)
terraform import genesyscloud_routing_skill.basic 12345678-1234-1234-1234-123456789012

# 2. Import Skill Groups (depend on skills)
terraform import genesyscloud_routing_skill_group.main 22345678-1234-1234-1234-123456789012

# 3. Import Users (depend on skill groups for assignments, but often safe if you skip assignments initially)
terraform import genesyscloud_user.agent 32345678-1234-1234-1234-123456789012

# 4. Import Routing Queues (depend on skill groups and users)
terraform import genesyscloud_routing_queue.main 42345678-1234-1234-1234-123456789012

If you’re using the genesyscloud provider’s export tool, make sure you’re using the --ignore-dependencies flag if available, or manually edit the exported HCL to remove the cyclic references. I usually comment out the member_ids in the skill group until the users are imported.

Also, watch out for the genesyscloud_routing_email_domain resource. It often gets tangled in these cycles if you’re importing email routing rules. Import those last.

The error message you posted cuts off, but it’s likely genesyscloud_routing_queue → genesyscloud_routing_skill_group → genesyscloud_user → genesyscloud_routing_queue. Breaking that loop by importing users without queue assignments first usually fixes it.

You’ll also want to verify the state file after each import batch. Run terraform state list to ensure the IDs are correct. If you see a mismatch, you’ll need to terraform state rm and re-import.

This isn’t pretty, but it works. The provider team is aware of this issue, but for now, manual sequencing is the only reliable way.

3

Problem

purecloudplatformclientv2 resolves the state file issue when we apply the leaf node approach. You do not need to fight the provider cycle by pulling the base resources first. It is a quick Python script to handle the fetch before running the import.

Code

from purecloudplatformclientv2 import PlatformApiClient, RoutingApi
from purecloudplatformclientv2.rest import ApiException

api_client = PlatformApiClient('_client_id', '_client_secret')
routing_api = RoutingApi(api_client)
try:
 response = routing_api.get_routing_queue(queue_id='main-dr-queue')
 print(response.skill_group_ids)
except ApiException as e:
 print(f"Error {e.status}: {e.reason}")

Error

purecloudplatformclientv2 grabs the skill_group_ids references cleanly. The Terraform import runs green after that. I am still seeing a 403 on the analytics endpoint when the token expires mid-run.

Question

purecloudplatformclientv2 OAuth flow might require a specific scope for queue history. Does the refresh grant need an additional scope parameter for the analytics API?