How to work with external data in Flatfile

One of the most useful features when working with Flatfile is the ability to work with data outside of Flatfile. You have the ability to do things such as use Flatfile to clean the user data already in your system, compare new data to the current data in your system during an import and keep data consistent as edits are being made. In this guide, we will show you some of the most useful ways to use Flatfile with your external data source as well as help you avoid some of the common pitfalls when using an external datasource with Flatfile.

Initializing the importer with data

Common use cases:

• You have data in your database, and you need a user to verify its accuracy and/or make corrections.
• You have data in a 3^rd party tool, and you would like to use Flatfile to help migrate and clean the data before using it in your system.
• You have previously unfinished/unclean imports (maybe from before implementing Flatfile) that you need a user to finish.
• Using Flatfile as a way to edit user data in an ongoing fashion.

When we talk about initializing the importer with data, we are talking about bypassing the standard, "choose a file" style import to access some external data using Flatfile as a means of editing and submitting the clean data. During this process, you are able to provide feedback in terms of errors and warnings that will indicate to the user what may need to be corrected.

If you check out our

SDK reference, you will notice that there is an optional object (LoadOptionsObject) you can pass into the method to initialize the importer with data instead of a user file. When you pass in this object, the matching stage of the import (which would include field hooks and record init hooks) is skipped and you will go to the Review phase of the import. In all of the common use case scenarios above, this will be the starting point. It is useful to know that within the SDK reference, you will pass in the data, but can optionally pass in the sequence (index number) and any error messaging. We allow for different error messaging, and you can learn more about the levels of messaging here.

Let's take a look at an example of how this works. For a typical import, you might call the

method like in the below example:

For the sake of the example, we are taking Flatfile and launching an import using the

event of the which is assumed to be a valid element in your UI.

To make things easier to visualize, we are going to set a variable with some data and pass that into the method. Keep in mind that you can work with external data, but it will need to have the same data structure as what you see here.

Now, we can pass this object into the method as seen below:

And when the importer starts, your user would see the below screenshot.

Validating a field against an external datasource

Common use cases:

• Needing to make sure values being imported aren't duplicated in your system.
• Formatting data with functionality from your server.

Being able to validate your data against a server or use an external resource for formatting data is useful in the process for having clean data. With Field Hooks, you can send the entire dataset of a particular field to your server or some form of external validation. In the below example, we have used typicode's jsonplaceholder API to replicate having some data to validate against on a server. You can check out our data on GitHub, but what we are looking for is to make sure that there are no emails in the following data that are already on our server.

First Name	User ID	Email
David	0001	david@flatfile.io
John	0005	john@doe.com
Paula	0009	paula@fakeemail.com

Below is what the code would look like for validating this against the external datasource.

What happens in the example with the data provided is that the first row comes back showing that the email is already in the data and is a duplicate value.

Using record hooks with external data

You can also use record hooks with external data. The key thing to remember when using record hooks with an external datasource is that these do not run as one bulk operation like field hooks, but rather run on each individual record. So while it is absolutely possible to use record hooks on initialization of the importer, it is best practice to use field hooks on initialization for working with external data, and then use record hooks on

to keep the information updated. In this example, we will add onto the fields hooks example from above, but we will add the record hooks validation to the change event to make sure that when a record is updated, we didn't update an email address to one already listed in the system.

Notice that with the record hooks we added here, we are verifying that the

(which can be thought of as the record hook event) is before proceeding to perform a server call. Filtering out the hooks here prevents the code from running each record individually on initialization which could cause as many server calls as there are records in the file.

If you want to learn more about Data Hooks and their best practices, you can check out our guide on Data Hooks best practices.