Parameterize Linked Service in ADF with no Dynamic Content available

When you create linked services in Azure Data Factory (ADF) or in a Synapse Workspace, you typically want to parameterize certain properties of the connection. When you deploy your artefacts to another environment, you can change the parameter values to switch the connection to the new environment. For example, the server name of the connection pointing to your data warehouse is (hopefully) different between your development and production environment. During deployment, you change the server name from the dev environment to the server name of the production environment. You don’t want your production jobs accidentally updating your development environment.

You can parameterize linked services by adding “dynamic content”, which is ADF-speak for parameterizing a property. In the following screenshot, you can see the server name has been parameterized using a parameter with the (obvious) name server. When you deploy ADF/Synapse workspace, you can then change the default value of this parameter between environments.

However, in some linked services some properties don’t have the ability to use dynamic content. For example, the Microsoft 365 linked service doesn’t support parameterizing the service principal ID that is used to connect to the Microsoft 365 Graph.

It’s possible that you use a different service principal in production then in development, so what to do? Luckily, we can force parameterization by doing it ourselves in the JSON. In the linked services menu, hit the curly brackets next to the linked service name to show the JSON code:

In the JSON, we can see the hardcoded value for the service principal ID:

We can replace this with a parameter:

"servicePrincipalId": "@{linkedService().servicePrincipalId_office365}",

At the bottom of the JSON, we then need to add a section where we declare this parameter. You need to specify a name, a type and a default value.

        "parameters": {
            "servicePrincipalId_office365": {
                "type": "string",
                "defaultValue": "my_service_principal_id"
            }
        }

The entire JSON (the secret of the service principal is fetched through Azure Key Vault):

{
    "name": "Microsoft365_Graph",
    "properties": {
        "type": "Office365",
        "description": "Graph Data Connect to extract data from O365",
        "annotations": [],
        "typeProperties": {
            "office365TenantId": "365 tenant ID",
            "servicePrincipalTenantId": "Azure tenant ID",
            "servicePrincipalId": "@{linkedService().servicePrincipalId_office365}",
            "servicePrincipalKey": {
                "type": "AzureKeyVaultSecret",
                "store": {
                    "referenceName": "mykeyvault",
                    "type": "LinkedServiceReference"
                },
                "secretName": "service_principal_secret"
            }
        },
        "connectVia": {
            "referenceName": "AutoResolveIntegrationRuntime",
            "type": "IntegrationRuntimeReference"
        },
        "parameters": {
            "servicePrincipalId_office365": {
                "type": "string",
                "defaultValue": "my_service_principal_id"
            }
        }
    }
}

The only “downside” is that you lose the user interface to edit the linked service, as now the entire definition has become dynamic content:

Once the linked service has been properly parameterized, you should be able to change the parameter value in your devops pipelines.