How to parametrize the referenceName for Linked Service Reference in the Datasets part for only 1 parquet dataset.

Hi @Dina

The dataset validation fails because the linked service reference is no longer recognized when linkedServiceName.referenceName is replaced with a dataset parameter expression.

Regarding your original question, there is currently no supported way to parameterize linkedServiceName.referenceName for only a single dataset through arm-template-parameters-definition.json. Custom parameterization rules are applied at the resource type level and cannot target individual dataset instances. As a result, if you parameterize the linkedServiceName.referenceName property for the Parquet dataset type, the rule applies to all Parquet datasets of that type.

Similarly, datasets cannot be grouped based on the linked service they reference for the purpose of ARM template parameter generation.

To reduce the number of generated ARM parameters and stay within the 256-parameter limit, the recommended approach is to keep dataset linked service references static and parameterize the linked service properties themselves (for example, server name, storage account, database, endpoint, etc.). This typically results in significantly fewer deployment parameters.

If a single dataset genuinely needs to reference a different linked service in PROD, a common approach is to use a dedicated linked service for that dataset and manage the environment-specific differences at the linked service level rather than at the dataset reference level.

The behavior you observed during validation therefore indicates a limitation of the parameterization model rather than an issue with your implementation.

References:

• Use custom parameters with the Resource Manager template https://learn.microsoft.com/azure/data-factory/continuous-integration-delivery-resource-manager-custom-parameters

• Parameterize linked services in Azure Data Factory https://learn.microsoft.com/azure/data-factory/parameterize-linked-services

• Datasets and linked services in Azure Data Factory https://learn.microsoft.com/azure/data-factory/concepts-datasets-linked-services

Please let us know if you have any further questions.

Hello @Jerald Felix ,

Thank you for your answer but unfortunately didn't work.

I followed the Option 2.

For the example I used an AzureSQLTable type dataset.

These are the steps that I followed:

1)

1. 
2. But then as you can see the validation failed and there is no linkedservice reference for the dataset

Also the parameter removed from the parameters section.

Why is this happening?

Maybe there is no option to parametrize only one dataset for linked service reference?

Did I do anything wrong?

Thank you

Hello @Jerald Felix ,

Thank you for your answer but unfortunately didn't work.

I followed the Option 2.

For the example I used an AzureSQLTable type dataset.

These are the steps that I followed:

1)

2. 
3. But then as you can see the validation failed and there is no linkedservice reference for the dataset

Also the parameter removed from the parameters section.

Why is this happening?

Maybe there is no option to parametrize only one dataset for linked service reference?

Did I do anything wrong?

Thank you

Hello Dina,

Greetings! Thanks for raising this question in Q&A forum.

You have identified the root cause precisely. The arm-template-parameters-definition.json file works on type-level rules, not on individual resource instance names. As the official Microsoft documentation explicitly states: "A definition can't be specific to a resource instance. Any definition applies to all resources of that type." This means there is no supported way in the definition file syntax to say "only parameterize the linkedServiceName.referenceName for dataset named MySpecificParquetDataset" while leaving the other 36 Parquet datasets un-parameterized.

So the answer to your direct question is: no, you cannot target a single named dataset for parameterization in the arm-template-parameters-definition.json file. However, there are three solid approaches to solve this problem and stay within the 256-parameter limit.

Option 1: Parameterize the linked service at the linked service level instead (Recommended)

Rather than parameterizing the referenceName inside each dataset, parameterize the connection string or relevant property inside the linked service itself. If both environments use linked services with the same name but different backend connections (which is the most common DEV-to-PROD pattern), you only need one parameter per linked service in the ARM template, not one per dataset. This keeps your dataset definitions clean and reduces parameters drastically.

In your arm-template-parameters-definition.json, configure the linked services section like this:

{
  "Microsoft.DataFactory/factories/linkedServices": {
    "*": {
      "properties": {
        "typeProperties": {
          "*": "="
        }
      }
    }
  },
  "Microsoft.DataFactory/factories/datasets": {
    "Parquet": {
      "properties": {}
    },
    "Json": {
      "properties": {}
    }
  }
}

This removes all dataset-level parameterization entirely and puts the environment-specific differences where they belong, at the linked service level. Each linked service generates only one or two parameters, not one per dataset referencing it.

Option 2: Make the one special dataset use a dataset-level parameter for its linked service (not ARM-level)

This is the cleanest pattern for your specific case. Instead of trying to use the ARM parameterization system for one dataset's linked service reference, add a native ADF dataset parameter to that one dataset, and drive the linked service from it.

In the ADF studio, open the one Parquet dataset that needs a different linked service in PROD. Add a parameter to it, for example:

Parameter name: LinkedServiceName
Type: String
Default: DevLinkedServiceName

Then in the dataset JSON, reference it like this:

{
  "name": "YourSpecialParquetDataset",
  "properties": {
    "linkedServiceName": {
      "referenceName": "@dataset().LinkedServiceName",
      "type": "LinkedServiceReference"
    },
    "type": "Parquet",
    ...
  }
}

Now in any pipeline that uses this dataset, pass the correct linked service name as a dataset parameter at runtime. In PROD, your deployment parameters simply override the value of YourSpecialParquetDataset_properties_typeProperties_LinkedServiceName in the ARM parameters file to the PROD linked service name. Because this becomes a dataset-level parameter, it generates only one ARM parameter for that dataset instead of generating one for each of your 37 Parquet datasets.

Option 3: Remove the Parquet referenceName parameterization entirely and use a post-deployment script

If you want no ARM-level parameterization for datasets at all, remove the Parquet and Json blocks from your arm-template-parameters-definition.json so that no dataset generates any linked service parameters. Then add a post-deployment step in your CI/CD pipeline (a PowerShell or Azure CLI script) that updates only the one special dataset's linked service reference in PROD using the ADF REST API:

$token = (Get-AzAccessToken -ResourceUrl "https://management.azure.com").Token
$headers = @{ Authorization = "Bearer $token"; "Content-Type" = "application/json" }

$datasetJson = Invoke-RestMethod `
  -Uri "https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.DataFactory/factories/<adf>/datasets/YourSpecialParquetDataset?api-version=2018-06-01" `
  -Headers $headers

$datasetJson.properties.linkedServiceName.referenceName = "ProdLinkedServiceName"

Invoke-RestMethod `
  -Method Put `
  -Uri "https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.DataFactory/factories/<adf>/datasets/YourSpecialParquetDataset?api-version=2018-06-01" `
  -Headers $headers `
  -Body ($datasetJson | ConvertTo-Json -Depth 20)

This keeps your ARM template parameters lean and handles the one-off difference entirely in your pipeline logic.

Which option to choose:

Option 1 is the best long-term architectural fix if the real difference between DEV and PROD is the connection itself (storage account URL, server name, etc.) rather than a fundamentally different linked service type. Option 2 is the best fit if the linked service names genuinely differ and you want to stay within the ARM template model cleanly. Option 3 works well if you already have a mature CI/CD pipeline and want to avoid any ARM parameter changes at all.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.