Publisher Resource & Datasource

[AdamCoulterOz]

User Story

As a Terraform user, I want to manage Dataverse publishers through Terraform so that I can standardize solution publisher metadata, prefixes, and related records as code across Power Platform environments.

Use case: A platform team wants to provision and look up a reusable Dataverse publisher before creating unmanaged solutions, ensuring solution prefixes, choice value prefix behavior, and contact/address metadata are consistent and automated across environments.

Resource

• Resource Name: powerplatform_publisher
• Data Source Name: powerplatform_publisher
• Service Name: Dataverse Publisher
• Documentation Link: Publisher table/entity reference

Potential Terraform Configuration

resource "powerplatform_publisher" "example" {
  environment_id         = "00000000-0000-0000-0000-000000000001" # required
  uniquename             = "contoso" # required
  friendly_name          = "Contoso Publisher" # required
  customization_prefix   = "cts" # required

  # optional; if omitted, provider derives the same default used by the Power Apps UI
  customization_option_value_prefix = 77074

  description            = "Terraform-managed Dataverse publisher"
  email_address          = "publisher@contoso.example"
  supporting_website_url = "https://contoso.example"

  address = [
    {
      slot        = 1 # required, must be 1 or 2
      line1       = "1 Collins Street"
      city        = "Melbourne"
      country     = "Australia"
      postal_code = "3000"
      telephone1  = "+61-3-5555-0101"
    },
    {
      slot        = 2 # required, must be 1 or 2
      line1       = "100 Queen Street"
      city        = "Auckland"
      country     = "New Zealand"
      postal_code = "1010"
      telephone1  = "+64-9-555-0102"
    }
  ]
}

data "powerplatform_publisher" "example" {
  environment_id = "00000000-0000-0000-0000-000000000001"
  uniquename     = "contoso"
}

Additional Validation Rules

• environment_id is required and must reference a Dataverse-enabled environment.
• uniquename is required and treated as replacement-only.
• friendly_name is required.
• customization_prefix is required.
• customization_option_value_prefix is optional/computed; when omitted, derive it from customization_prefix using the same algorithm as the Power Apps publisher UI.
• address may contain at most 2 entries.
• address.slot is required for each entry and must be either 1 or 2.
• Only one address block may target a given slot.
• Resource id should be the raw Dataverse publisherid.
• Import should accept composite form <environment_id>_<publisher_id> and store the raw publisherid as state id.
• Data source lookup should support either id or uniquename.

API documentation

Action	Verb	URL	Status Codes	Comments
Create	POST	/api/data/v9.2/publishers	201, 204	Creates publisher, then provider reads back by returned publisherid.
Read	GET	/api/data/v9.2/publishers({publisherid})	200, 403, 404	Primary read path for resource.
Read by unique name	GET	/api/data/v9.2/publishers?$filter=uniquename eq '{uniquename}'	200, 403, 404	Used by data source and duplicate detection.
Update	PATCH	/api/data/v9.2/publishers({publisherid})	204	Updates mutable publisher fields and address slot fields.
Delete	DELETE	/api/data/v9.2/publishers({publisherid})	204, 403, 404	Deletes publisher if present.

JSON

{
  "uniquename": "contoso",
  "friendlyname": "Contoso Publisher",
  "customizationprefix": "cts",
  "customizationoptionvalueprefix": 77074,
  "description": "Terraform-managed Dataverse publisher",
  "emailaddress": "publisher@contoso.example",
  "supportingwebsiteurl": "https://contoso.example",
  "address1_line1": "1 Collins Street",
  "address1_city": "Melbourne",
  "address1_country": "Australia",
  "address1_postalcode": "3000",
  "address1_telephone1": "+61-3-5555-0101",
  "address2_line1": "100 Queen Street",
  "address2_city": "Auckland",
  "address2_country": "New Zealand",
  "address2_postalcode": "1010",
  "address2_telephone1": "+64-9-555-0102"
}

Definition of Done

• Data Transfer Objects (dtos) in dto.go
• Resource and Data Source Models in models.go
• API Client functions in api_publisher.go
• Resource Implementation in resource_publisher.go
• Data Source Implementation in datasource_publisher.go
• Unit Tests in resource_publisher_test.go and datasource_publisher_test.go for Happy Path, Error conditions, and boundary cases
• Acceptance Tests for resource and data source Happy Path
• Resource and data source added to provider.go and provider_test.go
• Example in the /examples folder
• Schema documented using MarkdownDescription
• Change log entry changie new -k added
• Run make precommit before PR

[mawasile]

@AdamCoulterOz if you need to create something that is a recrod in dataverse we have https://github.com/microsoft/terraform-provider-power-platform/tree/main/examples/resources/powerplatform_data_record for it.

Why do you need publisher as a part of IaC process? My understanding of using solution in IaC would be, that you bring a solution file as a black box to the IaC process, we don't want to support creating and configuring solution as a part of IaC process because that belong to application lifecycle, not infrastructure.

[AdamCoulterOz]

@mawasile - I don’t think publisher cleanly falls into “application lifecycle only”.

A Dataverse publisher is a stable platform object with its own lifecycle, identity, and downstream references. In particular, it is used as a prerequisite/configuration dependency for unmanaged solutions and solution creation flows in environment bootstrap scenarios.

That makes it a reasonable Terraform resource in the normal sense:

• it is a named remote object
• it has durable identity
• it participates in dependency graphs
• users benefit from drift detection, import, and typed schema rather than a generic record escape hatch

I also don’t think powerplatform_data_record is a strong substitute here. It is useful as a low-level escape hatch, but I would see that as a stop-gap in the absence of a typed resource. The fact that parts of Power Platform infrastructure are implemented as Dataverse tables does not, by itself, make them a good fit for generic record management from an idiomatic Terraform UX perspective.

I agree that importing a managed solution zip is application lifecycle. I don’t agree that all Dataverse records related to solutions are therefore out of scope for IaC. A publisher is closer to environment/platform configuration than to application content.

[mawasile]

looking at the overall use case now, I understand that you want to have the ability of creating publisher, solution and git integration as a single IaC process? In that case I think we can do it in order to make that whole use case simpler to buid nad manage as IaC