Flatfile

This article is for Flatfile's Portal 2.0, Portal 3.0, and Workspaces. If you'd like to check out the latest version of the Flatfile Data Exchange Platform, <a href="https://flatfile.com/docs/overview" rel="nofollow noopener noreferrer" target="_blank">click here</a>!

Matching is a step in your Flatfile workflow in which the fields of an uploaded file are paired with the fields of the corresponding data template. Data templates are defined on the Templates page. Matching is also done for enum values (category fields).

Flatfile does its best to automatically match uploaded data to defined data templates. To accomplish this, there are three levels of auto-matching, executed in the following order: exact matching, historical matching, then fuzzy matching.

Exact matching is executed when there is a 100% match (case is ignored) between the column header of the source data and the label and key of the destination template. In both Flatfile Portal 2.0 and Flatfile Portal 3.0, fields with exact matches are completed automatically for the user.

Historical matching uses previous matching decisions to match fields in a newly uploaded file. Fields with a historical match are completed automatically for the user.

- Flatfile Portal 2.0 uses JavaScript’s localStorage property, meaning that an individual user’s matching history is stored locally (in the browser) and used to inform future decisions.
- Flatfile Portal 3.0 stores all historical choices from production and test environments on the server, meaning we can reference any historical decision by the user, their colleagues, or any previous FF user regardless of the user session.

Fuzzy matching compares the column header to the list of field labels and keys to find approximate matches. Each match is given a score based on the similarity of the text and matched value. Field keys are considered more relevant, and weighted higher, than field labels. Anything with a score less than 40% won’t be suggested as a match. Flatfile Portal 2.0 shows only the most likely fuzzy suggestion as a match, while Portal 3.0 shows the user the top 3 matches to choose from.

1. Exact matching is executed when there is a 100% match (case is ignored) between the column header of the source data and the label and key of the destination template. In both Flatfile Portal 2.0 and Flatfile Portal 3.0, fields with exact matches are completed automatically for the user.
2. Historical matching uses previous matching decisions to match fields in a newly uploaded file. Fields with a historical match are completed automatically for the user.
 
 - Flatfile Portal 2.0 uses JavaScript’s localStorage property, meaning that an individual user’s matching history is stored locally (in the browser) and used to inform future decisions.
 - Flatfile Portal 3.0 stores all historical choices from production and test environments on the server, meaning we can reference any historical decision by the user, their colleagues, or any previous FF user regardless of the user session.
3. Fuzzy matching compares the column header to the list of field labels and keys to find approximate matches. Each match is given a score based on the similarity of the text and matched value. Field keys are considered more relevant, and weighted higher, than field labels. Anything with a score less than 40% won’t be suggested as a match. Flatfile Portal 2.0 shows only the most likely fuzzy suggestion as a match, while Portal 3.0 shows the user the top 3 matches to choose from.