Skip to content

Latest commit

 

History

History
28 lines (15 loc) · 5.79 KB

feature_request_guidelines.md

File metadata and controls

28 lines (15 loc) · 5.79 KB

Criteria for Including a Feature in the Terraform Provider

When evaluating new feature requests for the Power Platform Terraform Provider, maintainers should apply clear criteria to decide if a feature is in-scope (infrastructure as code) or out-of-scope (application lifecycle). Below are decision criteria derived from the design principles and guidance:

  • Is the resource/configuration a fundamental part of environment or tenant setup? If yes, it likely belongs in Terraform. (Examples: environments, data policies, security roles assignments, connectors, connections, tenant settings.)

  • Is it a solution component that should be developed and managed via ALM? If yes, it should be kept out of the provider’s scope. (Examples: canvas app definitions, flow definitions, tables/columns in Dataverse that your app uses, form or view customizations, etc. These are better handled by solution export/import and source control.)

  • Does the feature represent an integration point between Power Platform and other infrastructure? If so, consider including it. Many IaC use cases involve stitching together Azure and Power Platform (for instance, linking an environment to an Azure Key Vault via an environment variable of type secret, or configuring a App Insights connection). If the provider can manage that config (and it’s not already done via solution), it adds value as infrastructure code. This could sometimes mean adding data sources for application resources that are written during solution install like environment variable definitions.

  • Is the item solution-aware? If a feature inherently travels with a managed solution (like a connection reference or environment variable definition, or a chatbot component), then adding provider support for creating or manipulating it directly usually conflicts with ALM best practices. Such requests should be declined or redirected to use solutions. If the item is not solution-aware (like certain admin settings, or environment-level parameters that aren’t in the solution), provider support is more justified.

  • Does implementing this feature in Terraform encourage anti-patterns? The team is cautious not to enable workflows that go against Microsoft’s guidance. For example, a request to allow Terraform to directly update a canvas app’s formula would be an anti-pattern (bypassing source control and ALM governance). Similarly, using Terraform to load large reference data into Dataverse would be abusing it as a data migration tool, which is out of scope. If a feature request would lead users to manage application logic or data improperly via IaC, it should be declined. On the other hand, if it fills a legitimate gap (like configuring something not covered by current ALM APIs), it can be considered.

  • Is there an existing Microsoft-supported way to achieve the request? If Power Platform provides an explicit method (via PAC CLI or admin center) that is meant to be used in pipelines, the provider would prefer not to duplicate that unless there’s a strong demand for Terraform-native handling. Often the answer might be: use the PAC CLI or pipelines for that task. The provider’s documentation may simply reference those tools for certain needs, underscoring complementarity rather than implementing everything.

  • Maintenance and Security implications: The maintainers also consider whether adding a resource is maintainable and secure. For instance, if an API is undocumented or might change, or requires storing credentials (like connection secrets) in state, they might be hesitant. They opted for a loosely-typed” data record approach for Dataverse config to avoid having to add hundreds of minor entities as first-class resources. They will likely continue to balance adding strongly-typed resources vs. relying on generic mechanisms. If a feature can be handled by the existing generic resources (powerplatform_rest or powerplatform_data_record), they might not add a new dedicated resource unless there is significant benefit.

In practical terms, a feature request likely to be implemented is one that helps automate environment governance or setup that otherwise would be manual or separate – for example, “Enable managing tenant-wide analytics settings via Terraform” or “Support creating Dataverse teams (owner teams) via Terraform” – these align with infra management. A feature likely to be declined is one that asks Terraform to do what solution import/export or DevOps pipelines already do – e.g. “Add a resource to create a Power App and write its formulas” or “Create a copilot bot component via Terraform”. Those venture into app development territory, which is out of scope for IaC.

In summary, maintainers should ask for each request:

  • Does this belong in an Azure admin’s checklist or a Power Platform maker’s solution? If it’s the former, it leans towards Terraform; if the latter, it leans towards ALM.
  • Will managing this as code improve consistency and reproducibility of environments without undermining solution ALM? If yes, it’s worth doing. If it undermines or duplicates ALM, think twice.
  • Is this within the provider’s mission of platform administration, governance, and cross-cloud integration? If yes, it’s in scope. If it’s actually part of app feature rollout, defer to app ALM processes.

By applying these criteria, the provider team can maintain a clear boundary. The Terraform provider will cover the infrastructure of Power Platform (the “plumbing” needed for your solutions to run and be governed), while leaving the business applications to the tools designed for application lifecycle. This clarity will guide users to the right tool for each job and ensure the Terraform provider evolves in a focused, purposeful way.