Integration refers to any functionality that crosses systems. The Kinetic Platform can do everything from displaying a drop down of data maintained in a third party system to creating a record in a third party system. The many successful types of integration is one of the strongest and most flexible attributes of the Kinetic Platform.
There are three primary categories of integrations for the UI:
As such, the platform offers two integration tools for handling these:
These are configuration points set up by the Platform Admins with no need for the Form Developers to understand the details of the connections, the connected systems, or the back end in any way.
There are two basic workflow integrations:
As such, the platform has two different integration tools for handling these integrations:
These configuration points are all open source code written and provided by Kinetic Data or our customers and provided out on the integration area of Community.
While front end integrations are not limited to the low and no code solutions provided with the platform, these solutions do provide fast and simple ways to connect out to other resources:
The Agent provides a centralized place to store and manage the bridge adapters used to connect from external resources to bridges in the front end. Bridges allow platform managers to set up these connections to external resources with user friendly attribute names (for example, Last Name for sn in Active Directory) and the queries the form developers might need. This leaves the form developers to simply pick the query, fill in any parameters (variables) and off they go.
This wonderful, low-code way of connecting to external resources also centralizes management of these connections and queries. So if you need to change systems, you wouldn't need to touch all the forms using the bridge, just replace the mappings for that bridge to connect it to the new system.
The Agent also stores and manages all the files/attachments for the platform's front-end. This releaves the DB of the responsibility for managing, replicating, and storing the files, making the DB faster and more light-weight. It also allows the file storage and management to be done by systems built for file storage and management.
Webhooks are how the front-end of the platform connects to the workflow. Events trigger the webhooks to make calls to URLs, which are generally set up to call integrations. These are not limited to submission of form records, but extends far beyond that to multiple events for the space, users, teams, forms, submissions, and more.
Workflow integrations are divided into two parts, sources to handle and process incoming calls to start workflow and handlers to run the workflow process.
Sources process and parse the calls to run a tree in the workflow system so that the incoming data provided is simpler for the Workflow Developer to work with. A specific source is never required and all calls to the workflow engine could, potentially, come in on the ad hoc source, but this would mean all the data provided would be in the source data variable and would need to be parsed by the Workflow Developer. That would mean the Workflow Developer would need to know the format and content of that data for each source. Sources simplify that interaction. Sometimes they even make additional calls back to the calling system to be able to provide all the data that will be required for the workflow.
Handlers are snippets of code that run to execute the workflow process. These may process data or they may perform any sort of action (Create, Retrieve, Update, Delete) against another system. All that is necessary is that that system support an API connection. There are hundreds of handlers already available in the Integrations section of the Community and more are being added as they are built.
Also, since handlers and sources are both open source, it is possible to take existing ones to modify them for your own needs and systems. If you do and are willing to share, we will happily load them on Community for you.