Implementing Flatfile’s data onboarding platform: Avoid the coulda, woulda, shoulda

Upon hearing “You should…” you may automatically think you’re getting unsolicited advice, but in the case of implementing Flatfile’s data onboarding platform, we put together a list of ways to help guide you to a faster, easier, and better implementation.

You should...set your managed option to true .

This is an optional setting that when omitted, defaults to false. When you set this to true, you open up the ability to have .xls and .xlsx files work in the importer. You also get more visibility in the Flatfile Dashboard to see both the original file and the final version. If omitted, you will see an import history on this tab, but the files will appear blank and only have the headers in them. Check out more about the managed setting in our documentation.

You should...set devMode to true while you're getting things set up.

When in development, you might be importing files to test things out. You might upload dozens or even hundreds of test files to ensure it's configured properly and ready to go. You don’t want to be charged for these test imports, right? Without the devMode setting set to true, you will be. What's the actual difference between this being true or false? The UI displays messaging that will let you know that it’s in development mode. Once you’re done and ready to deploy to your application, you can either set this key to false or remove the key all together and you'll be locked and loaded for your production Flatfile’s data onboarding platform usage.

You should...use Data Hooks instead of regex validation to help out your users.

I’m not saying that you shouldn't use our regex validations. (You totally should. They're powerful and make sense to use in lots of places.) What I am saying here is that if you can use Data Hooks and reformat something or do something automatically with a few simple lines of code, then you should 1000000% do it that way. Consider this from a user's perspective and having a dates column where you set up your regex validation to be in MM/DD/YYYY format and the user brings you a file that is MM/DD/YY. Using regex validation, you can display an error message to let the user know their format isn't correct. You can even tell them the proper format for the date field, but in this scenario, they will still have to make the corrections. Using something like date-fns, you can re-format on their behalf and let them know you already took care of it. You still get clean data and now your users get an improved experience.

You should...use our field validations.

This might seem like a simple concept, but fields have the opportunity for lots of validation built into them with simple keys and values. You can make fields required, make fields unique, use regex (I promise it still makes sense to use in some cases) and then even do things like requiring one field if another field is present. We dedicated a ton of time into building out these validations. Digging into the product and setting these up will ensure that your clients have a solid experience importing their data - and that you get clean data. 

When it comes to implementing these “you should” steps, it’s a win, win, win situation where your clients win for having an easy import experience, you win because you get clean data and I win for having successfully guided you to set up Flatfile’s data onboarding platform more effectively from the start.

Interested in learning more about Flatfile’s data onboarding platform? Check out this short product overview video and stop wasting precious time and energy importing messy data files.