@microsoft/azure-data-factory-utilities: purpose of the factoryId parameter

Question

@microsoft/azure-data-factory-utilities: purpose of the factoryId parameter

Bánhidy Attila 40

Hi,

I have recently started using the @microsoft/azure-data-factory-utilities package to generate ARM templates in an Azure DevOps pipeline. It is working, and I am able to generate the ARM templates successfully. :)

However, I have a question about the second mandatory parameter of the validate and export commands. I could not find a clear explanation of its exact purpose in the official documentation.

I am referring to the factoryId parameter, which contains the Azure subscription ID, resource group name, and Data Factory name in the following format:

/subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/providers/Microsoft.DataFactory/factories/<factoryName>

My main question is:

During the validation or export process, does the Utilities package use this factoryId to access or retrieve any information from the corresponding Azure Data Factory resource?

For example, does it use the factoryId to retrieve or determine any of the following?

Data Factory configuration or properties

ARM template parameter configuration

arm-template-parameters-definition.json or any equivalent configuration

Environment-specific values

Any other information from the existing Data Factory that affects validation or ARM template generation

Or is the factoryId used only as an identifier/context for the validation and export process, without reading configuration from the actual Data Factory resource in Azure?

The reason I am asking is that we have multiple Data Factory environments in the same Azure subscription, with different resource groups and factory names. It is currently somewhat difficult for us to dynamically determine the correct factoryId in the pipeline.

Therefore, I would like to understand whether using a different but valid Data Factory factoryId could have any impact on the generated ARM template or the validation result.

I hope my question is clear. If any additional information or an example would help, please let me know.

Thank you!

SIVASANKAR YEDDULA 170 Reputation points Microsoft External Staff Moderator

2026-09-05T16:39:11.62+00:00

Hi @Bánhidy Attila ,
Thank you for reaching out to the Microsoft Q&A forum.
Based on the published documentation for @microsoft/azure-data-factory-utilities, the validation and ARM template generation process operates on the Azure Data Factory artifacts contained in the rootFolder, which represents the Git repository content. The utility uses the same validation and ARM template generation logic as Azure Data Factory Studio.

The factoryId parameter is a required identifier that specifies the Data Factory resource in the following format:

/subscriptions//resourceGroups//providers/Microsoft.DataFactory/factories/From the available documentation, there is no indication that the utility uses factoryId to retrieve configuration, parameterization rules, environment-specific settings, or other metadata from an existing Azure Data Factory resource during validation or ARM template generation. Those inputs are expected to come from the repository content being validated and exported.

Therefore, based on the documented behavior, the rootFolder should be considered the source of truth for validation and ARM template generation, while factoryId provides the Data Factory identity and context required by the utility.

As a result, using a different but valid factoryId would not be expected to cause the utility to load or merge configuration from that Data Factory into the generated ARM template. However, it is still recommended to use the correct factoryId, as it represents the intended Data Factory context and may be reflected in generated resource identifiers, names, or references.

That said, Microsoft documentation does not explicitly describe the utility's internal implementation details. Therefore, while the documented behavior suggests that ARM template generation is driven by the repository artifacts in rootFolder, only the product engineering team could definitively confirm whether factoryId has any additional internal usage beyond resource identification.

In summary, the documentation indicates that rootFolder provides the artifacts used for validation and export, while factoryId provides the Data Factory identity/context. There is no documented evidence that the utility reads configuration or settings from an existing Azure Data Factory resource during the validation or export process.

Thanks & Regards,
Microsoft Q&A forum.

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Based on the documented behaviour of @microsoft/azure-data-factory-utilities, the source of truth for validation and ARM template generation is the content in the rootFolder, which contains the ADF artefacts exported from Git. The utility runs the same validation and ARM-template-generation logic used by ADF Studio against those files.

The factoryId parameter primarily provides the data factory resource identity in the format: /subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/providers/Microsoft.DataFactory/factories/<factoryName>

From the public documentation, there is no indication that the utility uses factoryId to retrieve:

Existing data factory configuration from azure
arm-template-parameters-definition.json
Environment-specific settings
ARM parameterisation rules from a live factory
Other factory metadata that influences template generation

Those artefacts are expected to come from the repository content being validated/exported, not from the target data factory resource.

Therefore, using a different but syntactically valid factoryId should not cause the utility to load or merge configuration from that ADF into the generated ARM template. However, I would still recommend using the correct factory ID because it represents the intended Data Factory context and may be reflected in generated resource identifiers and references.

For CI/CD pipelines, a common approach is to construct the factoryId deterministically from pipeline variables rather than dynamically querying Azure: /subscriptions/$(subscriptionId)/resourceGroups/$(resourceGroup)/providers/Microsoft.DataFactory/factories/$(factoryName)

In short: rootFolder provides the ADF artefacts being validated and exported, while factoryId provides the identity/context. It is not documented as a mechanism for reading configuration from an existing Azure Data Factory.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.