With every release of Airkit we strive to make the system easier to use for both new users and for power users. There are a handful a major changes in this edition that for existing users might take a moment to understand how things have adjusted - most notably is that we've changed the Journey building experience from a flow chart to a more linear and objective experience.
Additionally we've noticed that many of our developers are sending reminder SMS and Emails for users that might be stuck in the middle of the process to help nudge them along - we've made this a primary feature of the new journey building experience with delays and notifications that are easier to setup and require no clean up (they auto-cancel as a user progresses or finishes the journey).
We look forward to seeing what experience you build with Airkit!
In CXR V18.0, we are sunsetting flow chart based approach and replacing it with a new linear and streamlined approach. There are many reasons but here are a few major considerations.
- The flow chart design was always additional work to make look pretty (events & actions) vs. just doing the more natural thing and making one page directly link to another.
- The conditional branching and reverse flows that are possible in a flow chart wasn’t as clean to promote funnels that need to be projected in a set of progressive serial steps
- Reminder nudges is a key feature of our Journeys, but the the branching & cyclical nature of a flow chart it was too easy to make mistakes that would accidentally send erroneous emails & sms message to end users
We recognize that change can be difficult, especially when it impacts one of our core builders. However, we’re prioritizing making things easier and more prescriptive for builders with the new Journey UI which forces a common area for triggers, and a set of named steps for a primary funnel to support our future analytic needs.
The Journey Builder can be used to outline the intended flow of the application. Plotting out the flow of a Journey in Steps lays the groundwork to treat the flow of an application as multiple discrete parts, or “Steps,” which can be assigned correlated actions directly within the Journey Builder. Each step can be associated with a Web Flow as well as an SMS or Email Notification.
When building out your application, you can go to the “Next Step” by using the Go to Next Journey Step action.
Apps can be built without use of the Journey Builder, the only thing that is required is if you are starting an application with a web link trigger, there must be one Journey Step added that denotes which web flow to navigate to.
For more information on the new “Journey” Builder, see: Journey Builder
Triggers Builder is used to define and manage how Journeys begin. This is also where you can create and manage App APIs. For more information on Triggers Builder, see: Triggers Builder
The Notifications Builder provides the tools to send outgoing Email or SMS messages that do not require a response through the same channel. These outgoing messages are referred to as Notifications. For more information, see: Notifications Builder
Notifications can be added to an individual Journey Step designated in the Journeys Builder, or they can be added as an Action on an Event.
Callout: If you want to send an Email Notification, you will need to set a value to
actor.email and initialize the Actor. A deeper discussion of why can be found here: Intializing the Actor
In order for notifications that are sent from a Journey step be TCPA Compliant, the
actor.time_zone must be set before the Initialize Actor on the Session Started event. This will automatically initialize a
calendarRestriction property on the actor. This will resolve to the correct TCPA calendar to use for the user. Delays added to the Journey will use actor.calendarRestriction as their restriction. For more information, see How To enforce TCPA.
Notifications are designed to be a one-way communication channel between a Journey and a user. They do not accept responses and can be used for cases such as nudging or reminding users. Chat Bots, on the other hand, are used if you intend to receive a response from the user. With Chat Bots, you can define and create decision trees or capture text responses.
Global variables, which were previously created in the Journey Builder can now be created in the new Variable tree. The variable tree is where you manage all of your variables across your application and can also put in sample data. For more information see: Variables Tree
Triggers, which used to be created using the Journey builder can now be initialized in two places.
- They can be dragged as a trigger in Journeys Builder
- They can be created in the new Triggers Builder.
Web Links do not have their own Event associated with them anymore.
- Depending on the use case, you can run actions on the Session Started Event, located in Connection Builder, or you can run actions on the Web Flow Updated event.
- If you want to do some more advanced actions associated with web links, such as adding query parameters you can create an App API and use the Response Headers to do a redirect to the canvas link.
Each app is now only associated with a single Starting Event, which will be triggered regardless of the channel used to begin any individual Journey. For example, a Journey might begin either when a new user navigates to a particular web link or calls a certain phone number. In either case, the same Starting Event would be triggered.
The Starting Event is accessible in the Connections Builder, under Global -> Session Started.
For a deeper discussion of this, see Starting Events.
Journey Events, which are now known as Session Events, can now be found in Connection Builder. Session Events are Action Chains that can be run from anywhere within your application.
Activity Events, which are Action Chains that can only be used within the Activities, can be configured in the Builder that they are created. For example, if an Activity Event was created in Web Flows Builder, it can be edited right from the Web Flows Builder by clicking the '+' icon to the right of the relevant Web Flow in the Tree and then selecting Event from the menu that appears.
App APIs are now created in Triggers Builder. They have been redesigned to operate a lot more like Data Flows, which provides much more flexibility. You can still start Airkit Journeys and run Events when a request gets made to the App API through using the Journey Mapping Data Operation and the Run Journey event Data Operation. For more information see: App APIs
Subscriptions can be created either through the new Journeys Builder or through Triggers Builder, though they are only editable in the Triggers Builder. Subscriptions can be used to kick off and start a Journey or lookup an existing Journey.
Connections Builder is where the global Events and data flows are located. The
Web Page Viewed, and
On Authentication Success events are now located in Connections Builder (previously in Journey Builder in the previous CXR version).