feat: add skip_capacity_state_validation to workspace resource and data source

[Copilot]

📥 Pull Request

❓ What are you trying to address

The workspace resource and data source call the List Capacities API to validate capacity state, which fails when the caller lacks capacity-level permissions — even if they have sufficient workspace permissions (e.g., Contributor). This makes data "fabric_workspace" unusable without Fabric Capacity admin rights.

✨ Description of new changes

Adds an optional skip_capacity_state_validation boolean attribute (default false) to both the workspace resource and data source. When true, the provider skips the validateCapacityState call that invokes the List Capacities API.

• schema.go: New skip_capacity_state_validation attribute. Resource: Optional+Computed, default false. DataSource: Optional. Excluded from list schema.
• models.go: SkipCapacityStateValidation field on dataSourceWorkspaceModel and resourceWorkspaceModel.
• data_workspace.go / resource_workspace.go: Guard validateCapacityState behind the flag. Preserve the field through resource Create/Update lifecycle (same pattern as Timeouts).
• tests: Two new unit tests covering the skip behavior for both data source and resource.
• docs: Regenerated via tfplugindocs.

Usage

data "fabric_workspace" "example" {
  display_name                   = "My-Workspace"
  skip_capacity_state_validation = true
}

resource "fabric_workspace" "example" {
  display_name                   = "My-Workspace"
  capacity_id                    = "00000000-0000-0000-0000-000000000000"
  skip_capacity_state_validation = true
}

☑️ PR Checklist

• Link to the issue you are addressing is included above
• Ensure the PR description clearly describes the feature you're adding and any known limitations

☑️ Resources / Data Sources Checklist

• Production quality implementation of the resource or data-source in ./internal/services
• Unit Tests and Acceptance Tests for your contribution in ./internal/services/<service_name>
  • Tests should pass and provide >80% coverage of your contribution
• Examples for your contribution in ./examples (see Terraform Documentation on examples)
• Schema descriptions for your resource or data-source in ./internal/services
• Docs templates in ./templates
• Updated auto-generated documentation in ./docs. (DO NOT manually edit ./docs - your updates will be overwritten)

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• checkpoint-api.hashicorp.com
  • Triggering command: /tmp/go-build1221566023/b001/workspace.test /tmp/go-build1221566023/b001/workspace.test -test.paniconexit0 -test.run=TestUnit_ -test.v=true -test.count=1 -test.timeout=2m0s -I ux-amd64/pkg/tool/linux_amd64/vet --gdwarf-5 openpgp/aes/keyw-atomic mpile ux-amd64/pkg/too-buildtags -p aform-provider-f-errorsas aform-provider-f-ifaceassert ux-amd64/pkg/tool/linux_amd64/vet -I y1305 -I ux-amd64/pkg/too-buildtags (dns block)
  • Triggering command: /usr/local/bin/terraform terraform version -stringintconv -tests /tmp/go-build1221566023/b875/vet.cfg ric-sdk-go@v0.14-errorsas ric-sdk-go@v0.14-ifaceassert ux-amd64/pkg/tool/linux_amd64/vet onfidential.go internal/httpcli-atomic mpile ux-amd64/pkg/too-buildtags -W g_.a mpile ux-amd64/pkg/tool/linux_amd64/vet . go/fabric/mlmode-atomic mpile ux-amd64/pkg/too-buildtags (dns block)
  • Triggering command: /usr/local/bin/terraform /usr/local/bin/terraform version -json -tests /tmp/go-build1221566023/b897/vet.cfg ric-sdk-go@v0.14-errorsas ric-sdk-go@v0.14-ifaceassert ux-amd64/pkg/tool/linux_amd64/vet -p checkpoint l/linux_amd64/cg-bool ux-amd64/pkg/too-buildtags -W g_.a /tmp/go-build377-ifaceassert ux-amd64/pkg/tool/linux_amd64/vet . go/fabric/sqldat-atomic mpile ux-amd64/pkg/too-buildtags (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[BUG] data "fabric_workspace" requires Fabric Capacity admin</issue_title>
<issue_description>### 🐛 What happened?

I'm running pipeline using Managed Identity having Workspace Contributor rights on "Workspace-Team1-2-DEV" workspace.

I expect that data "fabric_workspace" will return information about workspace without necessity of having Fabric Capacity Admin rights (which quite often is shared).

🔬 How to reproduce?

1. Grant account Contributor only for the workspace.
2. Allow account in developer settings for API queries.
3. Run TF code

data "fabric_workspace" "workspace_details" {
 display_name = "Workspace-Team1-2-DEV"
}

4. It will end up with error:
   ╷
   │ Error: Read operation
   │
   │ with data.fabric_workspace.workspace_details,
   │ on main.tf line 3, in data "fabric_workspace" "workspace_details":
   │ 3: data "fabric_workspace" "workspace_details" {
   │
   │ Unable to find Capacity with 'id': 4a4c7882-d123-4c99-b9da-11111111

5. After granting for the same user Fabric Capacity Admin role, the code executes properly and returns workspace details:

• workspace_details = {
  + capacity_assignment_progress = "Completed"
  + capacity_id = "4a4c7882-d123-4c99-b9da-11111111"
  + capacity_region = "Germany West Central"
  + description = "POC"
  + display_name = "Workspace-Team1-2-DEV"
  + id = "3213321-3232-32332-323232-3232-3232"
  + identity = null
  + onelake_endpoints = {
  + blob_endpoint = "https://germanywestcentral-onelake.blob.fabric.microsoft.com"/
  + dfs_endpoint = "https://germanywestcentral-onelake.dfs.fabric.microsoft.com"/
  }
  + timeouts = null
  + type = "Workspace"
  }

🏗️ Code Sample / Log

code:

data "fabric_workspace" "workspace_details" {
 display_name = "Workspace-Team1-2-DEV"
}

error:

│ Error: Read operation
│ 
│   with data.fabric_workspace.workspace_details,
│   on main.tf line 3, in data "fabric_workspace" "workspace_details":
│    3: data "fabric_workspace" "workspace_details" {
│ 
│ Unable to find Capacity with 'id': 4a4c7882-d123-4c99-b9da-11111111

📷 Screenshots

No response

📈 Expected behavior

Account having workspace level permission, should be able to read workspace details without necessity of having admin rights on the Fabric Capacity.

🌌 Environment (Provider Version)

1.6.0

🌌 Environment (Terraform Version)

1.12.2

🌌 Environment (OS)

Linux

📎 Additional context

No response

🔰 Code of Conduct

• I agree to follow this project's Code of Conduct.</issue_description>

<agent_instructions>See the issue and the proposed solution, and implement it based on best practices and consistent with the existing code and architecture.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@badeamarjieh hi @slawchod, thanks for reporting the issue. we were able to reproduce and identify the problem. we will keep you updated! @badeamarjieh hi @slawchod The provider calls [List Capacities](https://learn.microsoft.com/en-us/rest/api/fabric/core/capacities/list-capacities?tabs=HTTP) API to validate that the capacity is Active. This is intended to protect the provider users from scenarios where you apply terraform plan with 1. workspace assigned to an **active** capacity 2. at least one item in this workspace

and then the capacity gets suspended. In this case, rerunning terraform apply would break the state as all items inside this workspace will have not found as API response.

The user does not have to be an admin role on the capacity, rather contributor is enough </comment_new>
<comment_new>@badeamarjieh
Hey @slawchod
The permission on the capacity is controlled from the Fabric Portal and not from Azure: https://learn.microsoft.com/en-us/fabric/admin/capacity-settings?tabs=fabric-capacity</comment_new>
<comment_new>@badeamarjieh
The issue as described above:

"
This is intended to protect the provider users from scenarios where you apply terraform plan with

• workspace assigned to an active capacity
• at least one item in this workspace

and then the capacity gets suspended. In this case, rerunning terraform apply would break the state as all items inside this workspace will have not found as API response.
"

Whether it's a data workspace or a resource workspace, the issue still fits in both cases.

Unless the workspace capacity state is not returned in the Get Workspace API - we have to call the List Capacities API to check the state to not break the terraform state.

This is by design and not a bug...

• Fixes [BUG] data "fabric_workspace" requires Fabric Capacity admin #743

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.