[ISSUE] Issue with `databricks_permissions` resource

[caldempsey]

trafficstars

### Configuration
```hcl
data "databricks_service_principal" "foo" {
  # Your service principal configuration here
}

resource "databricks_permissions" "sql_warehouse_service_profile" {
  # Using display_name as documented (which is not a proper name, it's an ID) fails:
  principal = databricks_service_principal.foo.display_name
  # ... additional configuration ...
}

Expected Behavior

The documentation claims that using display_name is correct. In reality, this value is an ID—not a true name—and should just work or be accurately well-named.

Actual Behavior

Terraform fails with the following error:

Error: cannot create permissions: Principal: ServicePrincipalName(foo) does not exist

Switching to application_id resolves the error.

Steps to Reproduce

1. Define a service principal and a permissions resource as shown above.
2. Run terraform apply.
3. Notice that using databricks_service_principal.data_lake_reader.display_name produces an error.
4. Changing it to databricks_service_principal.data_lake_reader.application_id allows the configuration to apply correctly.

Terraform and Provider Versions

• Terraform: e.g., v1.3.5 (please adjust as necessary)
• Databricks Provider: [please replace with the version you are using, ideally the latest from https://github.com/databricks/terraform-provider-databricks/releases]

Is it a regression?

No, this is not a regression — it’s just confusing. We should deprecate usage of 'display_name' and add 'application_id', or let the display name seek for matching display names or identifiers (assuming they are unique).

Debug Output

TF_LOG=DEBUG output includes:
Error: cannot create permissions: Principal: ServicePrincipalName(foo) does not exist

Important Factoids

• The documentation misleadingly instructs users to use display_name for service principals.
• In practice, display_name is not a human-friendly name but an identifier, and using it results in the error above.
• The provider should either fix the behavior or update the documentation to clarify that application_id is required.

Would you like to implement a fix?

sure

[nkvuong]

@caldempsey could you let us know which section of the doc should be updated?

[plamb]

Adding to this. Neither resource.databricks_service_principal or data.databricks_service_principal document that application_id is an attribute of a service principal.

[alexott]

Hmmm: https://registry.terraform.io/providers/databricks/databricks/latest/docs/resources/service_principal#application_id-1 (for resource). For data source it's implied that it's also exposed as part of the input attributes.