/
CX Create / Flow Integrations

CX Create / Flow Integrations

Part of the CommFlow creation process is attaching the proper integrations for your needs. This article covers:

  1. What is an Integration?
  2. Connecting an Existing Integration to a CommFlow
  3. Configuring a Button Field to Interact with an Integration
  4. How Integrations are Created




1. What is an Integration?

  • Integrations allow you to transport CommFlow data to and from external web services and locations. Any time there is any data that needs to be imported into a CommFlow, or any data that needs to exported from the CommFlow/Script, an Integration must be used.

Integrations can do almost anything! CX Create currently runs integrations that do the following:

  1. Export call data to a client server for reporting
  2. Add a prefix to the order number identifying the call center
  3. Pre-authorize a credit card and/or run real-time order fulfillment 
  4. Authenticate a Promotional Code
  5. Calculate current sales tax rates
  6. Route the call to a Third Party Offer

The above list is just a sampling of what an integration can do. Want to send a real-time email to a caller? Use an integration. Want to populate your script with up-to-date information specific to the location they are calling from with one click of a button? Consider it done with Integrations! 

Integrations will fall into one of the following categories:

  • Behind-the-Scenes: sending or receiving outside data with no required interaction from the agent
    • Connected to the default SUBMIT and/or ABANDON fields on the script

      All scripts have these 2 options by default since every call ends in one of 2 ways: either a Submit (complete) or Abandon (incomplete). In the above image, the integration will run regardless of the session's outcome.

    • Connected to the Bill Address/ Ship Address/ Cart

      Once the Cart field is added, the Bill Address, Ship Address, and Cart options will automatically become available on the script node. The above image shows an integration configured to activate when the Ship Address field of the Cart is filled out.

  • Button-Triggered: requires the agent to interact with a configured button field to initiate a task and deliver a response

    When button fields are added to a script, they will automatically appear on the script node for connection to an integration. The above image shows that the script contains a button field labeled 'Authorize Card', configured to activate a credit card pre-authorization when clicked by the agent during the session.




2. Connecting an Existing Integration to a CommFlow

Integrations are added on the CommFlow Graph

  • Click on CommFlows in the left-hand navigation bar
  • Browse or search for the Title of the CommFlow you are looking for
    *For details on how to set up a CommFlow, click here.
  • Click to open it
  • Click on the  button to view the CommFlow graph
  • Click on Integrations in the left-hand navigation bar and drag it onto the CommFlow graph


  • In the New Integration pop-up, browse or begin typing the name of the Integration in the search bar


  • Click the title in the dropdown list to add it to the graph


  • Click on the Embed or the Script node field you are connecting to and drag into the integration node to connect them


Integrations connected to the Embed are designed to bring data IN to the CommFlow (adding a prefix, populating a field), and integrations connected to the script node are generally designed for extracting data FROM the CommFlow. 

Once the Integration is added to the graph, it may need to be mapped. Skip down to the section on Mapping the Integration.




3. Configuring a Button Field to Interact with an Integration

One of the integration types mentioned above was a button-triggered response. Once the agent clicks the button and the integration is fired off, there also needs to be some type of reaction inside the Script to let the agent know if the action was a success or failure. This is commonly done with a button and paragraph fields. Your setup may vary based upon your needs, but the following steps outline one of the most commonly-used integrations (CardConnect Aggregated, used to verify the authenticity of a payment card in real-time during a call) and what is required to configure it within a script.


We are currently working to produce a repository of integration templates that can be used by anyone. Once that is available, it will be posted here as a link.

Inside the script:

  • Add a button field and 2 paragraph fields to the bottom of the Credit Card Information slide 
    • Label: Verify
    • Button Text: Verify
    • Validity: [Always]
    • Enabled: [Always]
    • Visibility: All of the following:
      • If \ Credit/Debit Card \ is \ valid
    • Label: [Paragraph]
    • Prompt: Verify Successful
    • Visibility: All of the following:
      • If \ Verify \ response code is \ card:success

        *The text "card:success" is not selected from a list, but must be typed out manually, and must be typed exactly as it was programmed and appears in the Integration code. Many other integrations, like credit card processors use the codes success:true/success:false. Response codes vary greatly. For more details on this, skip down to the section Retrieving a Response Code From an Existing Integration.
    • Mirroring: n/a
    • Label: [Paragraph]
    • Prompt: Verify Failed
    • Visibility: Any of the following:
      • If \ Verify \ response code is \ card:invalid
      • If \ Verify \ response code is \ card:decline
      • If \ Verify \ response code is \ integration:timeout

        *As above, the response codes must be typed exactly as they were programmed. Variations like capitalizations, or extra spaces will not be recognized by CX Create, and the integration will not return a response.
    • Button
    • Paragraph
    • Paragraph

When a script utilizes an integration like this, it is common to set up the slide branching from here to proceed with the call ONLY IF the payment card is verified. Any failure means that no sale will take place, and the call should at that point, be dispositioned.

To set the slide branching using the integration response code:

On the Script graph, click on the branch that flows from the Credit Card Information slide to the Billing Information slide (or whatever slide is next in the sequence, according to the script directive).

  • All of the following:
    • If \ Verify \ response code is \ card:success


It should be noted here that once this button field is added to the script, you will not be able to advance past it using the Script Graph's Launch Preview feature. The slide will only advance based on the above branching conditions, which are dependent on a response code from the Integration, which can only be triggered in the CommFlow.




4. How Integrations are Created

Currently, CX Create only supports integrations that are programmed using moonscript.*
*For more information on programming with moonscript, click here.

Creating a new integration:

  • Click on Administration in the left-hand navigation bar to expand the dropdown list, and then click on Integrations

On the Integrations page, you can:

  • Click the  button to create an integration from scratch
  • Click the  button to import an integration (.json file) from another cluster
  • Browse or search for existing integrations by Label, Description, or the number of CommFlows it is used in.

The following actions are available to the listed integrations:

 Clone the integration and its settings

 Export the integration as a .json file

 Delete the integration


Creating an integration that is similar to one that already exists? Save time by cloning the existing integration, simply make the necessary changes, and save with a new Label (name).
Moving an integration from one cluster to another? Export it as a .json file, then use the Import Integration button at the top to save it into its new location.


Use caution when clicking the Delete button. CX Create will prompt you to make sure you want to delete it, and if it is currently connected to any CommFlows, it will display a warning:

Deleting an integration is a non-reversible action.

On the New Integration page, you can configure the following:

  • Step 1 General tab
    • Label
    • Description

  • Step 2 Advanced tab
    • CommFlow Data - returns data as collected from your CommFlow
    • Constant - text values that do not change
    • Calculated - define a calculation
    • Under the field label text box, is a dropdown menu for field type (defaults to Text)
      • Text
      • Name
      • Dropdown
      • Button
      • Radio
      • Checkbox
      • Address
      • Cart
      • Credit/Debit Card
      • eCheck
      • Constant
      • Calculated
      • sku
      • Number
      • "Credit/Debit card":{"number":"4111111111111111","exp_year":2020,"last_four":"2334","type":"visa","exp_month":4}
      • For ALL of the pieces to be captured by the integration, it must be written into the moonscript (located on the Request/Response Scripts tab of the Integration) as:
        • data['accttype'] = input.data.map.PaymentCard.type  data['account']  = input.data.map.PaymentCard.number  data['expiry']   = string.format('%02d', input.data.map.PaymentCard.exp_month) .. (tostring(input.data.map.PaymentCard.exp_year)\sub 3, 4)  data['cvv2']     = input.data.map.PaymentCard.cvv
      • Field types available include:
      • When mapping to a field that was used in the script, the field types should match up
        for example: Payment Card in the above image is a Credit/Debit Card type field in the script. Fields like Credit/Debit Card are comprised of multiple parts (card number, card type, expiration month, expiration year) and must be written into the moonscript individually.
        Whereas data from the Credit/Debit Card field looks like this:
    • http/https
    • ftp
    • sftp
    • email
    • Method- this is the type of action that will be taken when using http/https
      • GET*- retrieve data only
      • POST*- data is created for storage or submittal
      • PUT- data is recreated or updated in its entirety
      • PATCH- data is partially updated or modified
      • DELETE- removes a specified resource
      • HEAD- same as the GET method without returning a response
      • OPTIONS- used to test the status of the server
    • Data Type
    • Fields- These are request/response parameters, sometimes taken directly from the API response that you are integrating with. These fields must be mapped here manually.
      For example, if the response code includes the following:
      {
      "PaymentCard":"some data",
      "Token":"23j32n32d9ujd2",
      "TestMode":"False",
      "response_code":200
      }
      Then, the fields that need to be mapped are:
    • Protocol
    • Timeout- how long the integration will attempt its request
    • Retries- how many times the integration will re-attempt a failed request
    • Retry Delay- how long the integration will wait between retries

    • If Protocol = http/https

* GET and POST are the most commonly used methods and are the chosen option 95% of the time when using http/https.

      • Host- URL of the resource being requested
      • Port- port number of the resource being requested
      • Path- file system path of the resource being requested
      • Secured Connection [checkbox]- transmission occurs over a secured connection
      • Authentication
        • None- no authentication applied
        • Basic- uses unencrypted coding
        • Digest- credentials are encrypted
      • Content Type- (a.k.a. Media Type or MIME Type) The 2-part identifier for file formats and format contents transmitted on the internet
      • User Agent- name of the software sending the request on behalf of the user
      • Allow Redirection [checkbox]- should the API permit redirects to web pages using more than one URL address

    • If Protocol = ftp (file transfer protocol)
      • ASCII- file is transferred as text (.txt, .asp, .html, .php)
      • Binary- file is transferred as raw data (.wav, .jpg, .gif)
      • Host- URL of the resource being requested
      • Port- port number of the resource being requested
      • Path- file system path of the resource being requested
      • Secured Connection [checkbox]- transmission occurs over a secured connection
      • Username- user login for the ftp site
      • Password- user password for the ftp site
      • Transfer
      • Passive [checkbox]- allows the connection configuration to be done on the server side

    • If Protocol = sftp (secure file transfer protocol)
      • Best Match- this is the only available option so this must be selected if using encryption
      • Host- URL of the resource being requested
      • Port- port number of the resource being requested
      • Path- file system path of the resource being requested
      • Encryption
      • Authentication Key- Location to upload the private portion of the generated authentication key
      • Username- user login for the sftp site
      • Password- user password for the sftp site
      • Enable Host Key Validation [checkbox]- option to validate the public portion of the authentication key

    • If Protocol = email
      • Targets- address(es) the data is being sent to 
      • Source- address the data is being sent from
      • Subject- subject line of the email that will be generated
    • Request/ Response scripts

      Moonscript code for the integration's Request and Response can be typed directly into or copied and pasted in the text area of their respective tabs.




Mapping the Integration

Earlier, we added an existing Integration to the CommFlow Graph. Now that we've seen how these integrations are created, we can see whether or not it's necessary to map any fields on the Integration node.

If fields are to be mapped, they are taken from the API response.
For example, referring to the CardConnect Aggregated integration again, the following fields were mapped on the Step 2 Advanced tab:

  1. PaymentCard
  2. Token
  3. TestMode
  4. response_code

Of these 4 fields, it should be determined which are of use to the agent, and should be mapped for visibility in the Session Details. In this case, the relevant information includes PaymentCard, Token, and TestMode only.

On the CommFlow Graph:

  • Click the wrench to access the integration's settings
    • From here, you can either  or  the fields
  • Click on the Auto Map button
    • This will automatically pull the 4 field that were mapped on the Advanced tab

      *For this example, not all of the information was available.

    • Select Credit/Debit card from the Session Field dropdown list next to PaymentCard
    • Click on the  to delete the response_code entry.


  • Click Update to save and close the integration node




Retrieving a Response Code From an Existing Integration

Once the integration is created, it is connected to the CommFlow's Embed or Script node as mentioned above. Button-triggered integrations require that the response code be inserted manually into the conditions for the related paragraph fields that are configured to display the outcome of the integration's action.

These response codes can easily be retrieved from the Response section of the Step 2 Advanced tab (see above).

In the case of the CardConnect Aggregated integration, the first data.response_code = 'card:success'
If you scroll through the rest of the response script code, you will also find:

data.response_code = 'integration:timeout'
data.response_code = 'card:invalid'
data.response_code = 'card:decline'

Depending on the action taken by the integration, the response codes will vary. However, it is always imperative that they be copied into the script exactly (and without quotes) as they are programmed.