Subscribe now to stay up-to-date

Product updates & features

An introduction to Flatfile record hooks for validation

While there are many features that make the Flatfile Data Exchange Platform unique, the data healing elements, like Data Hooks, are among the most powerful. And it's not just Data Hooks! There are other constraints offered in the Platform that help ensure your data is imported seamlessly (and correctly).

In this post, we'll dive into field constraints you can leverage beyond Data Hooks.

Flatfile Blueprint

If you haven't spent much time digging into Flatfile Blueprint, you'll want to take a look at everything Blueprints have to offer. This is where you can set up your additional data validation. To use them, you'll add a constraints array to a field that contains each separate validator as an object.

Now that we've checked out the basic setup, let's talk about some of the specific constraints and what they do.

Required & unique validators

required & unique validators let you easily use one of our specific constraint types to generate additional validations. The required type will display a validation error for any blank values for this field. The unique type will throw errors for any duplicate values in a specified field, which can be especially helpful for de-duplication of records within a file. For example, we could receive an email address on every record and also ensure that an email isn't duplicated across the file.

We can set up the code as follows to obtain this behavior during imports:

External validators

The next type of field validators allow you to specify any pattern for validating the data against using the @flatfile/plugin-constraints plugin. You'll want to import the plugin that you can find documented here.

Here's an example where we create a length validator that sets the max length of 100 on the name field. If the name is over 100 characters, an error message will be added:

Composite uniqueness validators

The last type of validators are composite uniqueness validators. These Sheet-level validators can be split into two distinct strategies that define how to determine uniqueness. One is a concat strategy and the other is a hash strategy. An example of concat validation could be a situation where we specify that a first_name field and a last_name field together have to be unique.

The concat scenario via code is below:

To learn about all the available options for fields, check out the Flatfile Blueprint documentation here.