Terraform import failing on CXone Studio scripts with 'no matching resource' error

General Discussion
1

Trying to pull the full org config into Terraform for a DR test. Running terraform import on the studio scripts block is bombing out.

Here’s the block I’m using:

resource "nice_cxone_studio_script" "main_flow" {
 name = "Main IVR Flow"
 description = "Primary routing logic"
 script {
 # ... config here
 }
}

I’ve got the script ID from the UI. It’s a1b2c3d4-e5f6-7890-abcd-ef1234567890. I’m running:

terraform import nice_cxone_studio_script.main_flow a1b2c3d4-e5f6-7890-abcd-ef1234567890

The command hangs for a second then drops this error:

Error: resource nice_cxone_studio_script.main_flow not found for import

Importing custom resources requires that the resource be defined in the configuration.

I know the resource is defined. I can see it in the state file if I run terraform state list. The provider version is v0.1.12.

Is the import command expecting a different ID format? The API docs say the resource ID is just the UUID. I tried adding the org ID prefix, but that’s not a valid Terraform resource address.

I also tried fetching the script via the API first to make sure the ID is correct:

curl -X GET "https://api.nice.incontact.com/icapi/rest/v1/scripts/a1b2c3d4-e5f6-7890-abcd-ef1234567890" \
 -H "Authorization: Bearer $TOKEN"

That returns a 200 OK with the full JSON payload. So the ID is definitely right.

The error message is vague. It says “not found for import” but the resource exists. Is there a specific attribute I need to match in the HCL before running the import? Or is this a known bug with the Studio script resource type?

I’m stuck on this. The other resources like queues and users import fine. Just the scripts are failing.

2

Yeah, that error is annoyingly common when you’re trying to backfill state for Studio resources. The issue usually isn’t the ID format itself, but rather how the provider expects the identifier to be structured for the import command. Studio scripts in NICE CXone are nested resources, and sometimes the provider gets confused if you just pass the raw UUID without the correct context or if there’s a mismatch in the remote state vs local config.

First, double-check that your nice_cxone provider version is up to date. Older versions had a bug where the import endpoint didn’t handle the script payload correctly, leading to that “no matching resource” ghost error.

When running the import, make sure you’re using the exact resource address from your config. It should look like this:

terraform import nice_cxone_studio_script.main_flow a1b2c3d4-e5f6-7890-abcd-ef1234567890

If that still fails, try pulling the raw JSON payload of the script via the API first to see if there’s a hidden character or encoding issue. You can do that with:

curl -X GET "https://api-us-1.nice.incontact.com/api/v2/studio/scripts/a1b2c3d4-e5f6-7890-abcd-ef1234567890" \
 -H "Authorization: Bearer $TOKEN"

Look for any special characters in the name or description fields. Terraform is pretty strict about UTF-8 encoding. If the name has a trailing space or a non-breaking space, the import might fail silently or throw that generic error. Clean up the name in the UI, save it, and try the import again. Also, ensure your local state file is completely empty for that resource before re-running. Sometimes a partial state from a failed run blocks the new import.