Portal Capabilities
Last updated
Last updated
Portals are dashboards that make it possible to view and edit data stored in Airdata without accessing anything under the hood. Most Portals are built out for use by teammates that have been assigned the role of Agent, which does not grant them permission to work within Airkit Studio proper. A single Airkit app can be associated with only a single Portal, but that Portal can consist of arbitrarily many Portal Pages. Portals and Portal Pages can be created in the Portal Builder.
Most components of an app build can be fully emulated by Previewing the app, but this is not the case with Portals, because Portals aren't part of an app proper; they're a tool for internal (though non-developer) users to view app-related data. Portals are not part of a user's Journey.
In order to test and confirm that a Portal is functioning as intended, the app needs to be published, at which point the Portal can be accessed by going to the URL associated with the Portal in Configuration Builder. For more on how to associate URLs with your organization, check out Connecting your Domain to Airkit.
Multiple Portals can be associated with a single URL. When this is the case, you can select the Portal you want to view by clicking on the icon in the upper left corner and selecting the desired Portal. The follow example shows what it looks like to toggle between two available Portals: Hello, Portals! and Portal Experiments.
.gif)
Portal Pages are displayed on the upper right of a Portal. To open the desired Portal Page, click on the one you want to view. The following example shows what it looks like to toggle between two available Portal Pages: Feedback Object and List Test:
.gif)
Additional Security
Permissions are usually dictated by the role of the user, but Portal Pages provide the option of additional security. Users, upon being invited or managed in the Console, can be assigned User Variables with associated values. Access to Portal Pages can then be limited only to users with User Variable/value pairs that match the User Variable/value pairs associated with the Portal Page, as specified in the Permissions section in the Inspector of the Portal Builder.
For instance, say you want to create a Portal Page that is only relevant to your Sales Team. You can assign every user on your Sales Team a User Variable called Team and give it the value "Sales." Then when finalizing the Portal Page, you can define the User Variable Team and also give it the value "Sales," so that only users with the matching User Variable/value pair – that is, users on your Sales Team – will be able to access the Portal Page.
When a user accesses a Portal containing a Portal Page they do not have access to, it will appear as though the restricted Portal Page does not exist at all.
One of the commonly used types of Portal Page is the Data Grid, which allows anyone accessing the Portal to interact with data stored in AirData. Each Data Grid is associated with an App Object. By default, a Data Grid displays the data that has been saved to the App Object in exactly the same way that the Stage displays the same information within the Data Builder. However, a key difference is that it's possible to change or limit exactly which properties of an App Object are displayed; this can be used to make the Data Grid more intuitive to non-developers and to limit the visible information to only that which is relevant to the people who will be regularly accessing the Portal Page. See documentation on the Portal Builder and Data Builder for more information on how to customize how data is displayed within a Data Grid.
In addition to allowing Agents to view information stored in AirData, Data Grids also make it easy for Agents to interact with data in various pre-approved ways. For instance, it is possible to download the displayed data as well as upload a CSV file that appends additional data to it. The Portal Builder also provides fine control over which object properties Portal viewers will have the capacity to edit and whether or not Portal viewers will be allowed to delete whole rows of data. One of the most powerful ways Portal viewers can interact with data in a Data Grid is by running Data Flows on select App Object instances.
By associating relevant Data Flows to a Data Grid, it's possible to streamline the most common data tasks. There are many possibilities for automation. A simple example involves a Data Grid that displays an App Object containing survey data with a column for email address. A Data Flow can be built that automatically sends follow-up emails to email addresses selected by the Portal viewer. Note that it can perform this Data Flow on any number of App Object instances at at time:
