CX as Code Roadmap

Platform API CX as Code
1

I've recently used Archy to assist my team in some regulation of style/code standards within architect flows. Now I've been asked to look at Scripts. One example of a script exported to JSON was 35k lines.
Are there any existing blueprints or any roadmap regarding this complex topic? The team work on multiple Orgs and in many cases scripts and flows are used in multipole Orgs so are manually replicated.

Second related question: Would it be wise for us to try and use CX as Code rather than Archy for Flows.

Third related question: I have not played with Terraform yet so do you know if it has any issues working behind a proxy (which some of our users are forced to use when on site). Archy suffers this issue.

2

Hi Paul,

A few things:

  1. Could you be a little more specific about what you are looking for related to scripting? Are you looking for a linter? Are you looking for an architecture doc for how writing flows/scripts. I would like to understand your use case a little bit better.

  2. Archy preceded CX as Code and it is relatively straightforward to integrate Archy directly into a CX as Code flow. We do have a flow resource in CX as Code, but it does have a couple of limitations:

  • Flows must be deployable within 15 minutes of time. We use AWS Lambdas in our CX as Code deployment process and they have a 15 minutes timeout window. So if your flows take more than 15 minutes you will need to use Archy to deployments.
  • The CX as Code component does not support the export of flow components. We are working with the Architect team on this capability, but we do not have an exact ETA.
  1. We do not currently support proxies in the Terraform provider. We can investigate this and see how hard it would be to implement.

Thanks,
John Carnell
Manager, Developer Engagement

3

Sorry that I wasn't clear. It's probably because I am quite new to the concept of developing via GUI and the cousin (to avoid developing by GUI) of developing by YAML. What I meant by scripts was contact centre scripts. The one I was looking at has 35k lines when exported and formatted with a JSON formatter. Granted many lines are containing just a curly brace. Within that script are 3500 UUID's. As an exercise of quality control I replace most of the UUID's with either the name of the external component such as customActions or I replace with the name of the internal component such as pages or variables. After this replacement there's less than 50 UUID's so it's easier to read but more importantly, easier to compare.

The purpose is to compare that 'normalised' script with the equivalent export from another Org to confirm that they are equivalent. I doubt whether the internal UUIDs need to be unique for the Org but I replaced them anyhow as I was not certain. Currently, when asked to work on a large script, our developers have two choices. Make a copy on the name org, replace any 'live' objects such as queues that calls might be sent to or datatables that might be used with replacement dev versions or replicate the script and all the objects (by name) on another Org. Both have pros and cons. We tend to use the latter for large overhauls as there's minimal changes needed when replicating back into production Org.

4

Hi Paul,

Thanks for the clarification. While we can deploy the configuration of a script, the actual script content and dependencies within the script are not managed by the CX as Code. That is why you are getting the UUIDs on exports. We do not currently support the exporting of these UUIDS within the scripts using CX as Code and do not have them on the roadmap. If this is a feature you would like, I recommend you post an idea for it on our Idea portal. Our product managers use votes from the ideas on the portal to drive new features.

Thanks,
John Carnell
Manager, Developer Engagement