Example of mapping Salesforce to the PassFort API

Before you build an integration between PassFort and one of your existing systems, you should consider how the data in your system will map to the data in PassFort.

What needs to be mapped?

These are the key PassFort entities, objects, and fields to map:

  • profiles: Entities that represent the individuals and companies applying to your products.
  • collected_data.customer_ref: An optional field on the profile. Use it to add your own unique identifier that you're using for the profile.
  • applications: An array of objects that exists on each profile. Each application is its own object in the array.
  • applications.id: The unique identifier of the application.
  • applications.product.name: The name of the product which the application is for.
  • applications.status: The stage that the application is at in the onboarding or monitoring process. See the possible values of the status.
  • applications.flag: What's currently happening to the application or what needs to be done for the application to progress to the next status. See the possible values of the flag.

If you're building an integration with Salesforce, you might choose to map this data as follows.

Each product application has its own lifecycle, so you should create your records at the application level.

Mapping PassFort profiles

Use the Salesforce object you're using for applicants (e.g. Accounts or Contacts) to map PassFort's profiles.

Then map the Salesforce object's AccountID field to the collected_data.customer_ref on PassFort's profiles so you have your own Salesforce reference in PassFort.

Mapping PassFort applications

In Salesforce, you can create a custom object called PassFort Applications, which you can use to map to PassFort's applications objects.

Give the PassFort Applications object a lookup field so you can relate the applications to the Salesforce object you're using for applicants.

Add these custom fields to the object:

  • Application ID: Map this field to PassFort's application.id field.
  • Status: Map this field to PassFort's application.status field.
  • Flag: Map this field to PassFort's application.flag field.
  • Product Name: Map this field to PassFort's application.product.name field.

Syncing the data during the product application lifecycle

These are the two most important webhooks to listen to:

  • Product status changed webhook: Lets you know when an application's status field changes in PassFort and what the value of the field is. Learn more about the Product status changed webhook.
  • Product badge changed webhook: Let you know when an application's flag field changes in PassFort and what the value of the field is. Learn more about the Product badge changed webhook.

When an application's status or flag changes, use the customer_ref returned in the webhook callback to lookup the matching Salesforce object you're using for applicants.

Next, use the application id returned in the webhook callback to find the Salesforce object's application with the matching Application ID, and update the application's Status or Flag field with the new data from the callback.

If the Salesforce object you're using for applicants doesn't have an application with a matching application id, create a new application.

There are other actions you may want to take when an application's status or flag changes (e.g. if an application's status is CANCELLED, you should revoke the applicant's access to your product). For a detailed explanation of how you might want to use statuses and flags, as well as a description of other webhooks you may want to listen to, see Manage product applications.


How did we do?


Powered by HelpDocs