These are really well-defined requirements and while it would be great to see the import Block include these in future updates, it could be a while and I have a hunch that no single developer could ever envision all of the nuances that would be impactful to your environment, or the vast possibilities that we all seem to encounter with import tasks.
Have you ever discovered an import tool that is perfect?
If someone asked me how to solve for “x” (where “x” is nearly every imaginable import theme, and many more that cannot be predicted), I would approach it from a data perspective. Indeed, the right approach is probably best discovered by abstracting everything about a data import recipe into a data model itself.
Hmmm… we need a database with an integrated scripting model that works with Airtable. Oh yeah - we have all that with the advent of Script Blocks. :slightly_smiling_face:
Each import recipe should be definable by anyone (where “anyone” is any information worker with an understanding of the import objective). A databased recipe dictionary would be ideal in a company with multiple locations and multiple import pathways from modern data sources that can be easily reshaped, to legacy sources that are rigid.
The beauty of a data-driven import solution is that changes, modifications, and subclassing can generally occur without making code changes. It abstracts all the moving parts of the solution to a configuration model whose behaviours are applied at import-time - literally, a late-binding approach.
Such a system would define and sustain the import “themes” as an actionable knowledge base of ways to move data into (and perhaps out of) Airtable bases. Each theme would identify the nature and author of the recipe.
There would be only one script block designed in a way to utilize the recipes as dynamic rules that anyone could use (straightaway), test (with a simulator), and fully document and manage as versions with utilization log analytics including who and when each recipe is used.
Indeed, all the items in @Justin_Hall’s wish-list could be met and lots more.
I would hesitate developing something like this as a Custom Script Block but I also wouldn’t rule it out. This is an app that falls into the “utility” category and it’s likely (at least in its early days) to require rapid change and feature enhancements. A Script Block implementation would make it far easier to start small and grow the tool over time, whereas, a Custom Script Block requires a far deeper investment in a framework, with deployment friction - simply not as agile.
If there are customers and/or Airtable developers who would like to partner with me to develop the coolest, easiest, and most agile import utility ever conceived, I’d be willing to help.
