Once the bridges have been set up in Space -> Plugins, you can use those bridges to set up the details of the bridge connection under Space -> Bridge Models. What attributes/fields are you going to pull back from any particular structure? What qualifications will be used to access certain data.
The Bridge Model general tab is where you set up/see the very basic of the bridge connection. This is where the bridge is specified, using the bridge slug, and where the structure being leveraged for this particular model is set up.
This is where the fields that will be returned by the bridge are specified. This sets up both the name of the field in the platform and what field that connects to on the source side are set up.
Qualifications are the queries, including dynamic parameters, that are set up for this model. Only these queries will be available to form builders. As many qualifications as necessary may be set up.
Once all the information is set up for the model, the test section can be used to test the bridge model. The desired fields returned and qualification can be specified. This helps ensure the bridge model is set up correctly before providing it to form builders for us and allows a troubleshooting interface for when issues arise.
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.