Terraform `genesyscloud_architect_flow` - State Drift on Published Flow ID

NICE CXone API & Integrations
1

Hi all, thanks so much for all the help lately - really appreciate it, I’ve been learning a ton. I’m running into something weird with the genesyscloud_architect_flow resource in Terraform - it’s kinda frustrating because it seems to work initially, but then drifts after a publish. We’re on Genesys Cloud, obviously.

So, the basic setup is we’re automating flow creation and publishing as part of our infrastructure-as-code pipeline - which is cool, but this drift is a blocker. The flow itself is pretty basic - just a simple greeting with a disconnect. When Terraform applies, it creates the flow, publishes it, and the published_flow_id attribute gets populated - that’s great. But if someone manually edits the flow in Architect after it’s been published (even if they don’t change anything significant, like just clicking “Save”), Terraform detects a drift on the next run.

The error I’m seeing is Error: differences detected. The plan shows Terraform wants to re-publish the flow - which is odd because the underlying flow definition hasn’t actually changed. I’ve tried adding lifecycle { ignore_changes = [published_flow_id] } to the resource, hoping it would just ignore this ID, but that doesn’t seem to do the trick. Terraform still wants to re-publish, and it’s causing constant diffs. I’m using Terraform version 1.5.7 and the genesyscloud provider version 3.22.0.

It feels like the published_flow_id is a read-only attribute that Terraform shouldn’t be managing, but it’s getting included in the state. I was looking at the API documentation - specifically /api/v2/flows/actions/publish - and it seems that publishing the flow just returns a new flowId, so maybe that’s where the drift comes from.

I’m kinda wondering if there’s a better way to handle flow publishing with Terraform, or if this drift is something everyone just deals with and has to work around. YMMV, but it’s kinda breaking the idea of immutable infrastructure. It’s making the pipeline a bit noisy. It’s not causing failures, but it’s making the diffs huge and hard to review.

2

Honestly, the flow ID drift is… predictable. At my last shop, we ran into the same issue. Terraform’s state file gets the ID before GC actually commits the publish. Try adding a time.sleep(10) after the genesyscloud_architect_flow resource block - it’s a terrible hack, but GC’s API isn’t exactly known for its speed.

edit: And make sure you’re refreshing the Terraform state after the sleep, naturally.

4 Likes
3

That’s right, the API isn’t always instantaneous; the sleep is a reasonable stopgap, though not ideal. It’s a symptom of the eventual consistency model underlying the Genesys Cloud platform-changes propagate, but aren’t reflected everywhere immediately. Terraform, naturally, wants a stable ID to manage; it doesn’t inherently understand that propagation delay.

Instead of a fixed sleep, though, you could poll the flow’s status via the API until the published flag becomes true. It’s a bit more complex, but far more reliable. You’d need to craft a loop that calls the flow information endpoint repeatedly - maybe every 5 seconds - and check the published attribute. The Terraform resource can then use that verified ID. You’ll need a data source for that; something like this:

data "genesyscloud_architect_flow" "flow_status" {
 flow_id = genesyscloud_architect_flow.my_flow.id
}

resource "genesyscloud_architect_flow" "my_flow" {
 # flow definition...
}

output "published_flow_id" {
 value = data.genesyscloud_architect_flow.flow_status.id
}

This ensures Terraform only registers the ID after the flow is actually published; that’s a more solid solution.

edit: It’s important to add a timeout to the polling loop, otherwise, you’ll risk Terraform getting stuck indefinitely if something goes wrong during publish; maybe 60 seconds total.

4

That’s right, the API delay is the core of the problem. We’ve seen this also - it’s similar to a post from last month about data actions not being available right after a flow publish.

The time.sleep() is a workaround, but it’s not always reliable. Sometimes 10 seconds isn’t enough, sometimes it’s too much.

Instead of a fixed delay, we use a loop to check the flow’s status. You can get the flow details by querying the flow information. Check the published flag - it should be true. It’s a little more complicated than time.sleep(), but more stable.

Here’s an example of what that might look like in Terraform (you’ll need to adjust it for your environment, of course):

resource "genesyscloud_architect_flow" "example" {
 name = "My Flow"
 description = "A simple flow"
 // ... other flow config ...
}

data "genesyscloud_architect_flow" "published_flow" {
 flow_id = genesyscloud_architect_flow.example.id
 depends_on = [genesyscloud_architect_flow.example]
}

local {
 published_flow_id = data.genesyscloud_architect_flow.published_flow.id
}

You can add a count variable to check for the ‘published’ status, and loop until it returns true. It takes a few seconds, but it’s more predictable than just guessing a time. It’s a little messy, but it avoids the drift.

5

Okay, this is a really common issue when you’re automating deployments - it’s good you’re using Terraform, by the way, it really helps with repeatability. I’ve seen this drift with flows a few times, and it usually comes down to how quickly you’re trying to read the state after publishing. The API isn’t always instantaneous, as others have pointed out, but there’s a small thing that often gets overlooked.

Here’s a breakdown of how we’ve handled this, and a couple of things to check:

  • Confirm your Terraform provider version. We found an older provider version didn’t handle the asynchronous publishing quite right. We’re on the latest currently - it’s just a good first step to verify.
  • Review the flow’s publish settings. It sounds obvious, but double-check that the flow is actually publishing to the correct environment. We had an instance where a developer accidentally published to a test environment, and obviously the IDs didn’t match when we were expecting production.
  • Consider the impact of dependencies. Is this flow dependent on other flows or data actions? If so, those also need to be fully published and stable before Terraform tries to read the ID. A dependency chain can really extend the propagation delay.
  • The polling approach is good, but… ’ suggestion to poll the status is definitely the most reliable long-term solution, but you might need to adjust the polling interval. The default interval might be too aggressive - you might get a lot of unnecessary API calls. We usually poll every 30 seconds, but that’s just a starting point, it really depends on how busy the platform is.
  • What’s your overall deployment orchestration looking like? Are you using a CI/CD pipeline? Knowing the broader context of your infrastructure deployment might help pinpoint where the timing is off.