Settings That Know Their Target
Each Of 330 Settings Declares The Engines And Platforms It Applies To
August 14, 2026
Open the settings screen of most multi-target data tools and you get one long wall of options. Buffer sizes next to warehouse names next to notebook paths, all presented as if every knob applies to you. Most don't. And the ones that don't apply aren't just clutter, they're traps.
Set a buffer-tuning option in a project that generates Azure Data Factory pipelines and nothing happens. No error, no warning, no effect. Six months later someone reads the config, assumes it does something, and builds a decision on top of it. Dead configuration is worse than missing configuration because it looks alive.
BimlFlex takes a different position: configuration should be scoped the same way generated code is. Every one of the 330 settings in the catalog declares which integration engines and which target platforms it applies to. Pick your stack, and the settings in scope are the ones that can actually change your output. The rest are not part of your project's story.
Two Axes, Not One
A BimlFlex project makes two separate platform decisions, and the settings catalog tracks both.
The first is the integration template: the engine that runs your loads. There are five in the catalog, spanning the spectrum from SSIS through Azure Data Factory to Azure Databricks.
The second is the target system: where the data lands. That list is thirteen deep, running from SQL Server, Azure SQL Database, and Azure Synapse Analytics through Snowflake, Databricks, and Delta Lake to Oracle, Teradata, PostgreSQL, and MySQL.
These are independent choices. Azure Data Factory can land data in Snowflake, in Synapse, or in SQL Server, and each combination needs different things configured. So a setting can be pinned to either axis, and the two pins mean different things. A buffer knob belongs to the engine that moves the rows. A virtual-warehouse name belongs to the platform that stores them. A tool that treats "target" as one flat concept can't tell those apart; a settings catalog that carries both axes can.
Settings That Declare Their Scope
Here's what the scoping looks like on real settings:
SsisAutoAdjustBufferSize: SSIS projects only
AzureCopyDataIntegrationUnits: Data Factory projects
ApplyExtractConversionInDataflow: Data Factory projects
DatabricksUseUnityCatalog: Databricks projects
SnowflakeWarehouse: Snowflake targets, under any engine
SnowflakeAutoSuspend: Snowflake targets, under any engine
Roughly half the catalog applies everywhere: naming conventions, hashing rules, Data Vault semantics, the decisions that define your model rather than your runtime. Those travel with you across every engine and platform, which is the whole point of metadata-driven automation: the model outlives the stack.
The other half is pinned. Forty-two settings exist only for SSIS. Thirty-seven exist only for Databricks. Twenty-two apply only when the target is Snowflake, whatever engine feeds it.
That last group is worth a second look. Nobody sat down and decided which products should share which settings. The products share machinery, so the settings follow. The scoping falls out of what the platforms actually are.
A Map of Platform Differences
Which is the quietly useful part: the applicability of each setting doubles as documentation of how the platforms differ.
Why does AzureCopyDataIntegrationUnits apply to Data Factory projects and nothing else? Because Data Integration Units are a Copy-activity concept, and only Data Factory has a Copy activity. Why is buffer sizing SSIS-only? Because SSIS moves rows through an in-memory pipeline with tunable buffers, and Spark simply has no such dial. Every pinned setting answers a "why doesn't this exist over there" question about the platforms themselves.
The same awareness runs deeper than which settings show up. It reaches into what generated DDL is legal per platform. Take identity columns: SQL Server and Synapse will happily put an identity on a decimal column with scale zero. Databricks, PostgreSQL, Delta Lake, and MySQL only accept identity on plain integer types. Model a sequence key on a decimal and BimlFlex validates it against the platform you're actually deploying to, so you hear about the mismatch at design time instead of from a failed deployment script.
One model, different rules per destination, checked before anything ships. That's what target-aware means in practice.
What Scoping Buys You
The payoff shows up hardest during a migration. Move a project from SSIS to Azure Data Factory and the configuration change is legible: the SSIS-only settings retire, the Copy-activity and dataflow settings come into scope, and everything model-level carries over untouched. The diff between your old configuration surface and your new one is an honest summary of what actually changed between the platforms. Compare that with migrating a tool where every option nominally applies everywhere and you have to test each one to learn whether it still does anything.
Day to day, the benefit is smaller but constant. Reviews get shorter because the reviewable surface is only what's in scope. An auditor asking why a Snowflake warehouse never auto-suspends finds SnowflakeAutoSuspend in the Snowflake slice of the catalog, not buried between SSIS knobs it has nothing to do with. And the settings feed the same generation path as everything else in the model, so they version, branch, and deploy through source control alongside your entities, the discipline that BimlStudio templates then consume at build time.
The catalog isn't a ceiling, either. When a transformation you need has no setting, custom column-level transformations extend the generated output without leaving the metadata model. And the same scoping idea applies on the data side of the house, where one framework handles structured, semi-structured, and unstructured formats through the same metadata instead of separate tools.
The Question to Ask a Generator
When you evaluate any code generator, there's a cheap test that reveals a lot: change the target and watch the settings page. If nothing changes, the tool is telling you that configuration is your problem, that it will accept whatever you type and silently ignore what doesn't apply. If the surface adapts, someone did the work of mapping every option to the platforms where it's real.
BimlFlex did that mapping 330 times, across five engines and thirteen platforms. The generated code adapting to the target gets the attention. The configuration surface adapting with it is what keeps the config trustworthy for the years after.
