CX as Code FAQ
FAQs
Is there any additional cost or is this capability fully covered under the Genesys Cloud 3 licenses?
No additional cost. It is open source and uses our public APIs.
Since CX as Code is open source, is it supported by Genesys?
CX as Code is modeled after the MIT open-source license and support is "as-is". Please carefully review the license found in the CX as Code Resource Provider Github repository for specific details contained in the license. If you believe there is a defect in CX as Code please post your observation or question to our Developer Forum. The Genesys Cloud Developer Engagement team will evaluate at their discretion whether the defect will be addressed and will make a "best effort" to address any issues. This means that, unlike core Genesys Cloud products, CX as Code does not have guaranteed Service Level Agreements (SLA) or Service Level Objectives (SLO). The Genesys Cloud Developer Engagement team does monitor the Developer Forum and GitHub repo for defect reports. They add new features and fix defects on a regular basis to CX as Code.
Can I modify the CX as Code Terraform provider?
CX as Code is licensed under the MIT license. You are welcome to fork the project for your own use or you can contribute changes back to the project. Please be aware that while you may fork the CX as Code provider, Genesys Cloud is not responsible for supporting any of the changes made to a project you have forked. Contributions back to the CX as Code project will need be reviewed and if approved by the Genesys Cloud maintainers, merged. Support for any contributed and merged changes are still "as-is".
Currently there is support for the People, Permission, and Contact Center ACD objects. How does the roadmap look especially for more complex objects like scripts and architect flows?
For now, we are prioritizing object types based on customer feedback and plan to continue to add more over time.
How to get started with existing already configured Genesys Cloud organizations? Is it the best way to export your production org objects and then start applying them on each org to make sure the environments are consistent and then use the exported files as baseline under source control and update them and apply them through the path to production in your pipelines?
Exports from one Genesys Cloud organization can be applied to another Genesys Cloud organization. Please remember that this is not the primary use case for CX as Code. Terraform always attempts to create resources on the initial application of the export. It will not perform a "create or update" operation, which means resources with the same name that already exist in an organization where the export is being applied again will fail when the created Terraform file is run. Because of this, it works best if the organization where you import a config file too is a new Genesys Cloud organization.
Does CX as Code provide an audit trail of who changes to CX as Code resources and what changes were made?
The CX as Code provider itself does not create an audit trail of who has modified what Genesys Cloud objects defined inside the CX as Code/Terraform scripts. All CX as Code resource definitions are maintained as plain text file(s) and should be kept under the control of a source control system (e.g. Github, Bitbucket, svn, CVS). Source control systems will provide an audit trail of modifications made to the file.
How does it support environment comparison between two different Genesys Cloud environments?
There is no comparison support today. Exports from different Genesys Cloud Organizations can vary in resource order and naming, so a raw text comparison will likely be incorrect.
Is CX as Code well-suited for making one-time/infrequent bulk operations?
CX as Code is built as a set of lower-level primitives whose primary use case is to used to build and deploy resources via a CI/CD pipeline. While it is possible to do mass one-time provisioning or bulk operations with CX as Code, you will often find it more effective to use a scripting language and the Genesys Cloud API or build a solution using our Genesys Cloud CLI.
Are there any limits on the number of config objects that CX as Code will support?
We are not aware of any hard limits on the size of the Terraform config file. However, the CX as Code provider is built on the Genesys Cloud platform and its underlying APIs. Each CX as Code resource documentation lists the APIs that the resource provider uses. Those APIs are subject to Genesys Cloud rate limits. Please refer to our rate limit documentation for more details.
Can I use CX as Code for UI development?
The CX as Code project is a Terraform provider that wraps Genesys Cloud APIs (very similar to how CloudFormation wraps AWS APIs). The configuration is defined in a text file and creates/updates/deletes are processed by the Terraform CLI locally or by one of Terraform’s hosted offerings. This is not something that the Genesys Cloud UI would use.
Is CX as Code subject to API rate limiting?
The CX as Code provider may run into public API rate limiting if there are a large number of updates occurring, the provider will automatically retry with backoff logic to ensure a deployment will occur without errors. If you are interested in understanding more about API rate limits please visit our API rate limiting page.
Can I contribute to CX as Code?
CX as Code is open-source. You are welcome to open a pull request (PR) in the repo. Please be aware that submitting a PR does not guarantee it will be merged into CX as Code. All PRs are reviewed by the CX as Code maintainers (e.g. Genesys Cloud) and it is at their sole discretion if a PR is merged.
What should I do if I need a Genesys Cloud Object that is not supported by CX As Code?
There are three options:
- Create an Idea on Our Ideas Portal. Our product management team regularly uses the ideas portal to help prioritize work within Genesys Cloud.
- Contribute. CX as Code is open source. If you need an object and can not wait for Genesys to deliver the object, you are welcome to contribute directly to the project. The Genesys Cloud team will review, provide feedback and determine whether the contribution will be accepted. Once a resource has been contributed to the project, it will be supported by the Genesys team from now on.
- Use the Genesys Cloud API and integrate it into your Terraform script. The Terraform framework allows you to call out to command-line tools and scripts. If you do not want to contribute to CX as Code, you can still write a script that uses our SDKs/APIs to carry out the creation of the Genesys Cloud objects.
CX as Code is based on Terraform. Will Genesys run Terraform for my org?
Terraform requires customers to create an account with Terraform cloud or to run the Terraform CLI in their own infrastructure. If you need assistance with setting up CX as Code within your own environment or having Genesys manage your CX as Code deployment pipelines, please contact your Sales Account team to discuss professional service options
Does Genesys provide support for Terraform?
CX as Code is built on top of the Terraform tool set. Terraform is an open-source tool built and maintained by Hashicorp. If you believe there is a bug in the Terraform CLI, you are welcome to inquire about it on our Developer Forum. However, if the Genesys Cloud team believes the issue is related to the Terraform CLI, you will be directed to open an issue with Hashicorp's Terraform community.
Will I be able to see the changes made with CX as Code?
CX as Code is a Terraform provider. Every time a Terraform deployment occurs, Terraform will write a "plan" output to standard out. The "plan" output will show each object that is being added, updated, or deleted during the course of that run. It is your responsibility to save the output of a Terraform environment if you wish to maintain an audit trail of changes made during Terraform deployments.