Setting Up Bridge Details

Anne Rosebery
Platform Admins

Once the bridges have been built, you can use those bridges to set up the details of the bridge connection on the platform end. What attributes/fields are you going to pull back from any particular structure? What qualifications will be used to access certain data.

This is done in two steps: Setting up the Models and Setting up the Mappings.

Setting up the Models

Bridge Models model the data that will be received from the other system. Perhaps this will be a model for user data. You probably want data such as:

  • Name
  • Email
  • Username

And so forth. And you may want queries of:

  • All active (return multiple)
  • By Username (return single)
  • By Name (return multiple)

The All active query wouldn't need any parameters, but the By Username would take one parameter (perhaps called), as would the By Name (perhaps called Name).

This would be your model. At this point it doesn't matter what system you are connecting to. You know what data you want and what queries you want to make.

Setting up the Mappings

Bridge Mappings tie together the bridge models and the actual bridge data. They map the bridge provided data into the bridge model attributes and qualifications. The details of the mapping will be different depending on the details of the system being connected to.

For example, in the example above, we set up a model for user data. If that user data is in an Active Directory system, the models would map from the following fields:

  • Name: displayname
  • Email: mail
  • Username: samaccountname

But if that user data is in a Kinetic Platform, the models would map from these fields:

  • Name: displayName
  • Email: email
  • Username: username

The way they are mapped would be different as well. AD would look like this:

  • Name: ${fields('displayname')}
  • Email: ${fields('mail')}
  • Username: ${fields('samaccountname')}

And the Kinetic Platform mappings would look like this:

  • Name: ${fields('values[displayName]')}
  • Email: ${fields('values[email]')}
  • Username: ${fields('values[username]')}

This is because the record passed back from AD contains the desired attributes as fields of that record, but in the Kinetic Platform record that is returned, the fields that are returned are system fields such as id, createdAt, createdBy, values. Values is where the user defined fields on the form are returned.

Also, the queries would be formatted differently. For example, a query for user by username would be something like this for Active Directory


Because that is how an AD structured query would look, but for the Kinetic Platform, it would look something like:


Mappings & qualifications are all a matter of what queries the recipient system will understand and the data that that system will return.

What the Form Builders Need

Once the models and mappings are set up, all the form builders need is what is set up in the models portion of the bridge set up. They will be able to see these details in the form builder. This is why it is important these are useful and readable: such as Last Name rather than sn. Even if you are really familiar with the bridged system (such as Active Directory), the beauty of bridges is that your form builders don't even need to know what system they are talking to. You may decide to have a SQL DB for users in dev and your AD in prod, and as long as the bridge model attributes and qualifications are all the same, it doesn't matter what they map to.