How to handle the unknown: Dynamic configurations in Flatfile

Flexibility and customization are crucial for any developer working with data ingestion to handle data's diverse and dynamic nature. This article explores dynamic configurations in the Flatfile Data Exchange Platform, a powerful feature that allows you to configure a Space, Workbook or Sheet at runtime based on any data or use case you want.

Some examples of dynamic configurations include:

• Location-based: You can adjust the type of currency, phone numbers, or address format in the Sheet configuration based on a user's location.

• User type: Provide different configurations for different types of users. For example, admins can view and edit all fields, while non-admins have limited access to the data or view-only access for certain fields.

• Live data: Call an external API and use the returned data to determine how your Workbook should look. 

I know it's cliche, but the possibilities are indeed endless.

You can even dynamically update a live Workbook, Space or Sheet in place. A common use case is with workflows that involve multiple people who edit and/or approve the data. Once a user finishes with their edits, clicking on a "submit for review" button runs configuration code that changes data from editable to view-only, locking down the Sheet from further changes and notifying the person who needs to review it.

Sheets that update themselves

One Flatfile customer uses data from one Sheet to configure another Sheet on the fly. An admin user first uploads information about the data that will be ingested by end-users, then uses a custom action that creates a space for end-users based on the data the admin uploaded. This example shows just how flexible Flatfile is in solving data file import challenges, and in some cases, even reduces the dependency on developers.

Flexibility is the name of the game

Let's consider an alternate scenario of not having dynamic configurations in which your data import settings are static and predefined. In some cases, static configurations are the right solution, so this won't be an issue. But in other use cases, like if you need to adapt to changing scenarios or needs at runtime, you'll be stuck. Having to define configurations in a fixed manner leaves no room for modification without changing the code.

However, dynamic configurations change the game entirely. This allows you to be responsive to the needs of a user or a situation. For instance, if a user's location requires a different kind of currency in your Sheet, you can adjust the configurations dynamically to accommodate this not only when you initially set up your data import but even when certain events are triggered or data changes. Dynamic configurations allow you to adjust at runtime as well.

Consider the following JavaScript example demonstrating how dynamic configurations work in response to data updates:

This piece of code captures the essence of dynamic configurations. Once data in the 'Contacts' Sheet is updated (an event of 'commit:created'), the system moves on to perform the necessary configuration changes. This would not have been possible with static configurations.

How does it work?

Flatfile utilizes event-driven architecture, allowing code to be run at any point in time based on any activity, user interaction, or data logic. That code can validate or modify data and also update configurations.

For example, let's say you are configuring a new Space from the Flatfile dashboard.

When the “Create New Space” button is clicked on the platform, it triggers a job event within the space domain that initiates a configure operation. This operation is analogous to performing a POST request to the endpoint /api/v1/spaces with the parameter autoconfigure set to true.

1. Filter on the domain (space) and the operation (configure).

2. Listen for a job:ready event.

3. Build your Space 

4. Complete the job

5. Optionally, listen for new events that are spawned from within your space:configure job.

Next steps

Since everything is in code, Flatfile fully integrates into your software development lifecycle processes, making it easy to keep your app code and your Flatfile code totally in sync. Flatfile even supports multiple development environments like dev, staging, and production.

Want to try it out yourself with a detailed code example? Check out the Dynamic Configurations guide in our developer docs for some working examples, complete with links to the code in GitHub.