Learn the significance of terminology commonly used in Airkit documentation.

Everything built within Airkit is, at the highest level, sorted into Organizations, or Orgs for short. One must have access to an Org in order to access Airkit.

For more on how to add users to an existing Org, check out Adding Users to Airkit. For more on how to create a new Org, check out our Quickstart.

The Airkit Console is the part of the platform that provides access to Org-level material, making it possible to configure application resources, connect external integrations, and access all applications that have been created within the relevant Org.

Airkit Studio is the interface in which your Airkit apps can be created and edited. It consists of multiple Builders, each of which makes it possible to construct and edit different components of your apps.

The Journey Model describes a means of conceptualizing how Airkit keeps track of where users are within the flow of the application, as well as what they've done, entered, or requested in the process of going through it.

An Airkit Journey starts when a user first begins to go through the flow of an app. This can happen in a multitude of ways (see Starting a Journey for more information), but regardless of how a Journey starts, it spans all of the user's interactions with that app, across all relevant channels, as long as the app has some way of recognizing the Journey.

Every Journey has an Actor. The Actor represents an individual customer going through an Airkit App. Airkit uses information associated with each actor to help route incoming chat and voice interactions to the correct customer, which enables the platform to seamlessly transition between different channels. 

Web Flows are containers for Web Pages. Web Pages are containers for Web Controls, basic UI building blocks that allow users to interact with a web app.

Constructing Web Flows out of Web Pages and Web Pages out of Web Controls is how web apps are built in Airkit. This is done in the Web Builder.

Actions define how your Airkit applications interact with users, themselves, and the outside world; a series of Actions taken sequentially is called an Action Chain. For more on the types of Actions that can be taken, check out documentation on the Action Builder.

Events refer to any catalyst that might trigger an Action Chain. All Action Chains are associated with a particular Event. It is when – and only when – an Event is fired that its associated Action Chain is performed.

The different types of Airkit Events are:

Data Flows are custom connections. Conceptually, Data Flows work like functions: they take in input, process it, and return the resulting output (if applicable). 

Data Flows are made up of component parts called Data Operations, which define how input is processed. They are made and edited in the Connection Builder.

Airscript is a programing language specialized for data manipulation: it's by strategically combining Airscript with input from app users (or other external sources, such as an external API) that you control the order, flow, and nature of the interactions between your Airkit apps and the outside world. Most commonly, this is done by defining a variable with Airscript or by using Airscript to access or modify data via the Transform Data Operation, both of which parse any input in Airscript by default.

KitCloud Templates are pre-configured and customizable Airkit modules that can be used as building blocks to accelerate the development of app-building. They are available across Web Flows, voice bots, chat bots and Data Flows.

Did this page help you?