Skip to main content
Kinetic Community

Bridged Resources


Adding Bridged Resources to your Form and Kapp. Also a look at Datastores.


Bridges allow you to access data from systems external to Request CE. Examples include LDAP, ServiceNow, and Salesforce. For the purposes of this class we'll access data from the Admin Kapp (Datastore) and use it to simulate external sources.

Bridges break down into three parts, Model, Mappings, and Bridge Resource.

The Bridge is also a part of the Bridging console. In kinops this is not available, however customers are free to setup their own bridges and configure them to talk to other systems. Information on setting up BridgeHub is found here.

Bridge Model

The Bridge Model is an abstract representation of data from another system. For example, you want to reference customer information out your LDAP system, but you don't have precise knowledge of how it is stored there. You can create a model using abstract values.

Here is an example of a People Model:

Each Model can include two parts, Qualifications and Attributes.

Qualifications are just names (in this case By ID and By Last Name) with a type of expected result (Single or Multiple) and possibly Parameters. Parameters are optional values that are used by the qualification. However, they are also just names that will be replaced with actual values later.

Attributes are just labels for values that are expected back from the external system through the Bridge. These are the abstract/friendly names for use in the Bridge Resource and Form.

Attributes, Qualifications, and Parameters are all just abstract labels that are backed up by specific system information in the next section, Mappings.

Bridge Mappings

Bridge mappings are the specifics about the external system matched up with the abstract Bridge Model.

Here is the Mappings console that relates to the People Model

The people Model provides the basis for all the specifics of the mapping.

First, the mapping needs to be related to a specific Bridge. This is a URL provided by the Bridge Hub application. Along with the URL, the mapping is related to a structure. Structures vary depending on the system. For Request CE, it's Submission. For other applications it could be a table name, domain or form.

Attribute mappings apply the attributes from the model to the specific data from the bridged system. The example above is the format for mapping answers from Request CE.

${fields('values[First Name]')}

Our format always includes the ${fields('')}, and the specific identifier from the bridged system goes inside the single quotes.

Below the Attribute Mappings are the Qualifications

Qualifications are again dependent on the system. For the example below the qualification is appended to the URL of the rest API. You could have SQL statements, or application specific search strings. it all depends on the bridged system.

This is the qualification for by Last Name - kappSlug=admin&formSlug=people&values[Last Name]=${parameters('Last Name')}

Bridge Resources

The basic dialog for creating Bridge Resources.


  • Name - descriptive text
  • Status - Active is default
  • Model - refers to the Bridge on the Setup tab
  • Qualification - defined by the Model selected
  • Parameters - determined by the Qualification (if needed).

A common example is setting a default field when a page loads.

default bridge resource.png

The above Bridge resource is used to populate answers when a form loads using the default property.

default bridge setting.png

Another common example is setting a list from external sources. In our case we will set a list from the Datastore

bridge resources for list.png

If a bridge resource can return multiple values you have the option to sort them. However, this option is only available based on the source and the bridge.

bridge resource-sort.png

Overall Definitions are kept on the Form (covered later in class).


Add Bridged Resources to Forms and Form elements and question.