Genesys Cloud - Developer Community!

 View Only

Sign Up

  • 1.  genesyscloud_tf_export || Hardcoded-IDs in Queues

    Posted 6 days ago

    Hello everyone,

    I'm using Terraform for export the config that we have in PROD and configure our lower environments (DEV/QA). In general, is working fine, but recently I noticed that the parameter "enable_dependency_resolution = true" is not working correctly because:

    1) Don't obtain individual files for the dependencies of the queues
    2) All the values for queues dependencies are hardcoded ((divisions, wrapup codes and so on).

    I'll give you an example for groups (working properly) and queues (not working as expected):

    For schedule groups we use the following file:

    resource "genesyscloud_tf_export" "export" {
    directory = "./genesyscloud_architect_schedulegroups_output"
    include_filter_resources = ["genesyscloud_architect_schedulegroups"]
    include_state_file = false
    enable_dependency_resolution = true
    split_files_by_resource = true
    export_format = "hcl"
    }

    And we obtain the following output:

    e.g. Alex_Sch_Group_AllDayClosed_Test scheduleGroup


    resource "genesyscloud_architect_schedulegroups" "Alex_Sch_Group_AllDayClosed_Test" {
    closed_schedules_id = ["${genesyscloud_architect_schedules.ALL_DAY_TEST.id}"]
    division_id = "${genesyscloud_auth_division.Global.id}"
    name = "Alex_Sch_Group_AllDayClosed_Test"
    open_schedules_id = ["${genesyscloud_architect_schedules.C2C_US_Holiday_Juneteenth.id}"]
    time_zone = "Asia/Calcutta"
    }

    [...]

    As you can see, we obtain the dependencies for the "open_schedules_id", "holiday_schedules_id", "closed_schedules_id" and "division_id". We DON´T Received harcoded values. This is the behavior we expected, and we have noticed for different elements but queues.


    For queues, we have the following config file:

    resource "genesyscloud_tf_export" "export" {
    directory = "./genesyscloud_routing_queue_output"
    include_filter_resources = ["genesyscloud_routing_queue"]
    include_state_file = false
    enable_dependency_resolution = true
    split_files_by_resource = true
    export_format = "hcl"
    }

    But this is the output we obtain:

    e.g. AlexHM_Test2_Q queue

    resource "genesyscloud_routing_queue" "AlexHM_Test2_Q" {
    enable_manual_assignment = false
    last_agent_routing_mode = "AnyAgent"
    queue_flow_id = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
    auto_answer_only = false
    division_id = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
    [...]

    You can see that we have the IDs of queue_flow_id and division_id instead of the variables. It happens the same for:

    • wrapup_codes
    • queue_flow_id
    • members.user_id
    • media_settings_callback.answering_machine_flow_id
    • division_id
    • default_script_ids
    • on_hold_prompt_id
    • groups.member_group_id
    • outbound_email_address.route_id

    • Note: those outcomes were obtain using the following versions of terraform and genesyscloud terraform provider

      Terraform:1.14.8
      Terraform provider: version 1.78.0


    #CXasCode

    ------------------------------
    Ordisi Pomar
    IVR
    ------------------------------


  • 2.  RE: genesyscloud_tf_export || Hardcoded-IDs in Queues

    Posted 6 days ago

    Hi Ordisi,

    I checked the current CX as Code export docs and the current provider source, and what you're seeing with genesyscloud_routing_queue does not look like the intended behavior. enable_dependency_resolution is supposed to export dependent resources, and when include_state_file = false the exporter should favor Terraform references, omission of unresolved GUID fields, or generated variables rather than leaving raw IDs hardcoded in the output. That matches the behavior you're seeing for schedule groups.

    For queues specifically, the current RoutingQueueExporter() already declares reference handling for the fields you listed, including division_id, queue_flow_id, members.user_id, wrapup_codes, default_script_ids.*, on_hold_prompt_id, outbound_email_address.route_id, and media_settings_callback.answering_machine_flow_id. So if those are still being exported as literal GUIDs, I would treat that as a provider bug/regression or an unresolved queue-export edge case, not as a problem with your Terraform block.

    I also checked the current release status. v1.78.0 is the latest provider release right now, and while the changelog includes exporter fixes, I don't see a routing-queue dependency-resolution fix called out there. There is also an open routing-queue export issue for nested member-group references in bullseye_rings being emitted as GUIDs instead of Terraform references, which suggests queue export still has some dependency-resolution gaps.

    My recommendation would be:

    Keep your current export block; it looks valid.
    Temporarily set log_permission_errors = true so you can rule out missing GET permissions on dependent resource types while the exporter resolves queue references. The export resource calls GET APIs on the exported resource types.
    Run the same export once with split_files_by_resource = false, just to rule out output-format issues, since v1.78.0 includes a split-by-resource exporter output fix.
    Open a GitHub issue against the provider repo with a minimal repro and the exact queue attributes that remain hardcoded.

    So overall, I'd classify this as: valid configuration, unexpected genesyscloud_routing_queue export behavior.




    ------------------------------
    Marion Frigillana
    Senior PS Consultant
    ------------------------------



  • 3.  RE: genesyscloud_tf_export || Hardcoded-IDs in Queues

    Posted 2 days ago

    Hi Marion, hope you're doing well,

    I agree with your analysis, and I have opened an issue in the GitHub Repo:


    Unexpected genesyscloud_routing_queue export behavior: GUIDs instead of references · Issue #2299 · MyPureCloud/terraform-provider-genesyscloud

    I will make the "set log_permission_errors = true" and "split_files_by_resource = false" tests during this week and I'll update this post

    Thanks
    Ordisi



    ------------------------------
    Ordisi Pomar
    IVR
    ------------------------------