Most enterprises have Databricks workspaces deployed with both frontend and backend private links for security. The backend private link ensures the traffic between the control plane and data plane travels through the Azure backbone. The frontend private link dictates that anything that tries to access Databricks workspace from the UI, ODBC/JDBC connections, or Rest APIs needs to be in a private network. This means it will not work if you want to trigger Databricks workflows in a workspace with frontend private link to run directly from public internet (such as JIRA status change).

To make the trigger a workflow in a frontend private link enabled workspace successful, you need a midware, such as logic apps or functions, where inbound traffic and outbound traffic can be separately configured to be public internet and private network.

In the below, I show how to set up logic apps so that the networking components work as shown in the above diagram.

In summary, you will be follow below steps:

1. Create an additional subnet in the Vnet that Databricks is in ( in the video, the subnet is called la-connect). You can alternatively use vnet peering if you wish to.
2. Create a route table ( in the video, the route table is called lh-route-table), the route table needs to be in the same region as the vnet that Databricks is in.
3. Associate the newly created route table with 2 subnets: private-link and the additional subnet created (la-connect, in the video example).

Once the networking components are configured, you can create logic apps workflows as shown in the below example.

Consideration:

1. You want to parametrize as much as you can to make it reusable by different workspaces and jobs
2. You can replace logic apps with functions if you prefer a code-first approach
3. I used HTTP request trigger in the videos for demo purposes, you can swap it out for different triggers such as JIRA or other triggers that logic apps support.