I’m trying to reference an existing outbound routing rule in my Terraform config so I can attach it to a new campaign. The rule is already deployed in our London org, so I don’t want to create a new one. I figured using a data source would be the cleanest way to grab the ID without hardcoding it.
Here is the snippet I’m using:
terraform {
required_providers {
genesyscloud = {
source = "mygenesys/genesyscloud"
}
}
}
data "genesyscloud_routing_outbound_route" "existing_route" {
name = "Priority Outbound Route"
}
When I run terraform plan, it fails with this error:
Error: no matching resource found
with data.genesyscloud_routing_outbound_route.existing_route,
on main.tf line 12, in data "genesyscloud_routing_outbound_route" "existing_route":
12: data "genesyscloud_routing_outbound_route" "existing_route" {
I’ve double checked the name. It matches exactly what’s in the UI. Case sensitivity shouldn’t matter here. I also tried searching the API directly via Postman to /api/v2/routing/outbound/routes and filtering by name, and the JSON response comes back fine with the correct ID. So the resource definitely exists.
Is there a delay in the Terraform provider’s sync? Or am I missing a required attribute in the data source block? The docs are pretty sparse on this.
Have you tried using the genesyscloud_routing_outboundwrules data source with a specific name filter? The singular lookup can be tricky if the rule name isn’t an exact unique identifier in your org. I’ve seen this fail when there are slight variations in casing or if multiple rules share similar prefixes.
Here is a pattern that works reliably for pulling a specific rule by name:
data "genesyscloud_routing_outboundwrules" "my_rule" {
search_criteria {
name = "My London Outbound Rule"
}
}
# Extract the first matching ID
local {
target_rule_id = data.genesyscloud_routing_outboundwrules.my_rule.rules[0].id
}
resource "genesyscloud_outbound_campaign" "new_campaign" {
# ... other config ...
rule_ids = [local.target_rule_id]
}
One thing to watch out for is that rules is a list. If your search criteria match more than one rule, Terraform won’t know which one to pick unless you use rules[0] explicitly or narrow down the search criteria further. If the rule doesn’t exist, the data source will fail the plan, which is actually good for catching drift early.
Also, make sure the user running the Terraform apply has the routing:outbound:rule:view permission. We hit a 403 error last week because the service account lacked that scope, and the error message was vague. It just said “failed to read data source.”
If you’re still stuck, try adding debug = true to the provider block. It spits out the actual API call Genesys Cloud makes, which usually reveals if it’s a permission issue or a search string mismatch. The API path it hits is /api/v2/routing/outbound/wrules, so you can test that directly with Postman using the same search parameters.
Let me know if the list index approach helps. Sometimes the Terraform provider lags behind the API docs, so checking the raw response helps.