Working with Data
Airkit is designed to serve as an intermediary between multiple communication channels and external systems, all of which might have different data-formatting standards. Here, we'll discuss how to use Airkit to gather, store, and manipulate data before storing or sending out the results, either through a communication channel crafted in Airkit or via a call to another external system.
Gathering Data
In general, there are two ways to pull data into an Airkit application:
Collect information directly from the end user.
Pull information from an external system, either by requesting it or catching it.
Collecting information directly from the end user
Airkit provides several ways to collect data from end users. Some data, typically pertaining to the interface being used to access the application, is even collected automatically; for more on that, see Standard Journey Data. You can also collect data based on how users interact with your applications: user interactions can be used to define local variables, which can then be referenced downstream as needed.
For example, text messages sent to a Chat Bot or responses to a Voice Bot can both be used to define variables, and many out-of-the-box Web Controls allow or even require data binding to user input. One of the most commonly-used such Web Controls the Text Input Web Control, which is designed to collect user information in the form of strings. Once a user enters some text into the Input Box, that text will be stored as a local variable, which can then be accessed as needed.
Collecting information from external systems
Airkit provides simple, streamlined means of collecting information from external systems so that you can extend the capabilities of any and all platforms you're already using. This can be done in two ways:
Airkit can request data from an external system via a
GETRequest or something similar.Airkit can catch data sent from an external system via a Web Hook or something similar.
For more on how to request data from secure external systems, see the Integrations Overview. For more on how to catch data sent from external systems, see App APIs – or, if you're looking catch information from Zendesk or Salesforce, the two first-party integrations for which Web Hooks come configured out-of-the-box, see Subscriptions (Web Hooks).
Storing Data
Journey Data
Airkit conceptualizes locally-stored variables in terms of the Journey that they are a part of. Information collected as part of a Journey will be automatically accessible within that Journey and no others.
All variables within a Journey have an associated namespace, which defines where the variable is stored, as well as how and when the variable is accessible. This places limitations on the scope of individual variables, which is important for the sake of both security and application efficiency. For more on variable scope, see Variable Namespaces.
Long-Term Storage
AirData is Airkit’s internal database. It allows you to conveniently structure and access data collected by your Airkit apps. It also makes it easy for separate Airkit apps to share information via Datastores. While AirData is technically capable of long-term storage, it is intended primarily to be used as a convenient interim database, but not, ultimately, a source of truth.
Data gathered and manipulated by your Airkit apps is, at the end of the day, your own, and you can store it in whatever database you prefer. This is typically done by Integrating with your record system of choice. Some common record systems, such as Salesforce, are available as first-party integrations that come out of the box with special Data Operations that streamline the process of sending data. However, even with Custom Integrations, you can use the HTTP Request Data Operation to POST data. In such cases, Custom Data Types are often used to structure data in a format recognizable by the external database.
Working with Data
Once data has been pulled into a local Airkit Journey, it will often need to be reformatted or otherwise manipulated. To facilitate this, Airkit provides Airscript, an internal programming language focused on manipulating data in an intuitive but powerful way. To get started with Airscript, see the Airscript Quickstart.
You can find Airscript expression editors throughout the Studio. Whenever an input box contains the Airscript icon on the bottom right, that means that entered values will be parsed as Airscript by default. For instance, the following example shows two Airscript expression editors, one empty (left) and one containing an Airscript expression (right). Note the Airscript icon at the bottom right of both editors:
The icon to the both left can be clicked to expand the Airscript expression editor so that it opens in a larger pop-up in the middle of the screen. Expanding the Airscript expression editor makes it easier to define and edit more complicated Airscript expressions.
Special Data Types
To facilitate the data manipulation required in most common use cases, Airscript recognizes some special Object Data Types, which can be used in tandem with specialized functions to automatically handle some of the more notorious complexities. These Data Types are:
The first three of these are used to manage time-tracking while taking things like leap years and timezones into account. For more on how to use them, see Working with Dates and Times.
The last of these, Currency, is used to manage currency values while avoiding rounding errors.
When exchanging information with an external system, the external system will likely store date, time, and currency information in a different format than Airkit does. These differences will need to be explicitly managed, but Airkit comes with several Airscript functions that make managing the formatting discrepancies easier. For instance, TIMESTAMP_FROM_DATETIME converts a DateTime Object into a timestamp, and PARSE_CURRENCY converts standard currency strings into Currency Objects.
Last updated
