How should dependencies between entitlements and service instances be declared?

[leotardoo]

I’m trying to understand how to structure a Terraform configuration that assigns a service entitlement to a BTP subaccount and then creates a service instance using that plan.
If the service instance looks up its plan through a data source, how should I express the dependency on the entitlement? Is referencing the subaccount ID sufficient, or should the plan lookup explicitly depend on the entitlement resource?
Does the provider handle delays before a newly assigned entitlement becomes available, or does the configuration need additional handling?

[valkiara]

Put the dependency on the plan data source. Referencing the same subaccount ID in both blocks only makes them depend on the subaccount; it doesn't order the entitlement assignment before the plan lookup.

For the serviceplan_id approach, the relevant part is:

# Assumes btp_subaccount_entitlement.service is declared elsewhere.
data "btp_subaccount_service_plan" "service" {
  subaccount_id = var.subaccount_id
  offering_name = var.service_offering_name
  name          = var.service_plan_name

  depends_on = [btp_subaccount_entitlement.service]
}

resource "btp_subaccount_service_instance" "service" {
  subaccount_id  = var.subaccount_id
  name           = var.instance_name
  serviceplan_id = data.btp_subaccount_service_plan.service.id

  # Add the service-specific parameters here, if required.
}

The serviceplan_id reference gives the instance an implicit dependency on the lookup, so the chain is entitlement → plan lookup → instance. Adding depends_on only to the instance would leave the lookup free to run too early. SAP uses this pattern in its HANA Cloud Terraform tutorial.

If the entitlement is being created or changed, Terraform can defer the data-source read until apply; seeing (known after apply) for the plan ID is expected. See Terraform's dependency documentation.

There is also a newer option: provider 1.22.0 introduced service_offering_name and serviceplan_name on the instance, avoiding the separate lookup. In that configuration, put the explicit entitlement dependency on the instance itself. SAP's migration guide and exporter documentation describe it.

For the delay question, depends_on guarantees Terraform operation ordering, not that every downstream BTP API has already observed the entitlement. I wouldn't assume a universal propagation retry guarantee without the provider version and the actual error. Start with the dependency above; if the plan is still temporarily unavailable, capture a sanitized error and the Terraform/provider versions so the relevant retry behavior can be checked. A fixed sleep may mask the timing issue, but it isn't a readiness check.