🔷 Dynatrace VictorOps Notification Terraform Module

Manages a single Splunk On-Call (VictorOps) problem-notification integration (dynatrace_victor_ops_notification) against the dynatrace-oss/dynatrace ~> 1.98 provider — a standalone primitive with one keystone resource and no owned children.

• 📟 Renders exactly one resource — dynatrace_victor_ops_notification.this — a Splunk On-Call (VictorOps) notification channel that pages an on-call group when a problem matching an associated Dynatrace alerting profile opens.
• 🔗 Attaches to a pre-existing alerting profile by ID (profile); does not create, own, or validate that profile — see terraform-dynatrace-alerting-profile.
• 🔒 Treats both api_key and routing_key as sensitive, caller-supplied secrets — never a literal default, never re-exported as an output.
• 🧱 No nested block_types in the live schema — every attribute is flat, so main.tf is an unconditional, total 1:1 mapping from variables.tf with no dynamic blocks required.
• 🚫 Ships disabled by default (active = false) — a newly-applied integration cannot page anyone until the caller explicitly reviews and activates it.

💡 Why it matters: a VictorOps/Splunk On-Call integration that silently lacks a working API key, a message body, or an explicit activation decision is worse than no integration at all — it looks configured in the Dynatrace UI while quietly never paging anyone (or, if misconfigured the other direction, paging immediately on apply before anyone has reviewed it). This module's type contract (required api_key/message, secure-by-default active) makes both failure modes visible at plan time instead of discoverable only during a real incident.

If these Terraform modules have been helpful to you or your organization, I'd appreciate your support in any of the following ways:

• ⭐ Star this repository to help others discover this Terraform module.
• 🤝 Connect with me on LinkedIn: linkedin.com/in/microsoftexpert
• ☕ Buy me a coffee: buymeacoffee.com/microsoftexpert

Whether it's a star, a professional connection, or a coffee, every gesture helps keep these modules actively maintained and continually improving. Thank you for being part of the community!

flowchart LR
 AP["terraform-dynatrace-alerting-profile"]:::sibling
 TM["terraform-dynatrace-victorops-notification"]:::this
 KR["dynatrace_victor_ops_notification"]:::keystone
 VO["Splunk On-Call / VictorOps"]:::external

 AP -- "id to profile" --> TM
 TM -- "manages" --> KR
 KR -- "pages via routing_key" --> VO

 classDef this fill:#1496FF,color:#FFFFFF,stroke:#0B5FA5,stroke-width:1px;
 classDef keystone fill:#0A2540,color:#FFFFFF,stroke:#08182b,stroke-width:1px;
 classDef sibling fill:#E8EAED,color:#1A1A1A,stroke:#B0B4BA,stroke-width:1px;
 classDef external fill:#F5F5F5,color:#1A1A1A,stroke:#B0B4BA,stroke-width:1px,stroke-dasharray: 3 3;

This module sits downstream of terraform-dynatrace-alerting-profile (which owns the alerting profile's severity rules and event filters) and upstream of nothing in this catalog — no sibling module consumes a VictorOps notification's id today. Validated via the Mermaid Chart MCP before embedding (valid: true).

flowchart TB
 subgraph Inputs["Module Inputs"]
 name["name: string (required)"]
 profile["profile: string (required)"]
 api_key["api_key: string (required, sensitive)"]
 routing_key["routing_key: string (required, sensitive)"]
 message["message: string (required)"]
 active["active: bool (optional, default false)"]
 end

 R["dynatrace_victor_ops_notification.this"]:::keystone

 name -- "renders" --> R
 profile -- "renders" --> R
 api_key -- "renders, never logged" --> R
 routing_key -- "renders, never logged" --> R
 message -- "renders" --> R
 active -- "renders" --> R

 R -- "exposes" --> out_id["output: id"]
 R -- "exposes" --> out_name["output: name"]

 classDef keystone fill:#0A2540,color:#FFFFFF,stroke:#08182b,stroke-width:1px;

Validated via the Mermaid Chart MCP before embedding (valid: true).

Resource inventory:

Schema notes that bite (confirmed against the live provider schema, provider v1.100.0):

• api_key is the only attribute the provider itself flags sensitive = true. This module marks the corresponding variable sensitive = true and additionally elevates it from provider-optional to module-required — the provider would let apply succeed with no API key at all, producing an integration that looks configured but can never authenticate to Splunk On-Call.
• routing_key is not flagged sensitive by the provider schema, but this module marks it sensitive = true anyway — a deliberate house judgment call beyond the raw schema. A routing key is credential-adjacent (it directs alert traffic into a specific escalation group), so it gets the same "never print in plan/apply CLI output" treatment even though Dynatrace's own schema doesn't require it.
• Neither api_key nor routing_key is ever emitted as a module output — outputs.tf exposes only id and name, by design, regardless of the sensitive flag on either variable.
• message is provider-required with no documented default (confirmed "required": true in the live schema) — this module requires it explicitly rather than inventing a plausible-sounding default for a free-text field.
• active is provider-required with no server-side default — this module supplies a concrete module-level default of false (never null) so the rendered argument is always populated. This is also the secure-by-default choice: a newly-applied VictorOps integration is created disabled and cannot page anyone until the caller explicitly sets active = true.
• legacy_id is a computed, read-only attribute (the classic REST API v1 cross-reference ID) present in the live schema but not modeled as a module input or output — there is no documented consumer for it in this catalog.
• No nested block_types on this resource — every attribute is flat, so main.tf needs no dynamic blocks and no try(x, null) guards (every variable that reaches the resource block is already guaranteed non-null: five variables are required with no default, and active carries a concrete default).

dynatrace_victor_ops_notification is Settings 2.0-backed (schema ID builtin:problem.notifications) and accepts either OAuth client credentials/platform token or a legacy API token. This is not an IAM/Account Management or Platform/Automation resource, so no account-idm-* or automation:* scopes are needed.

• OAuth (recommended) or platform token: settings:objects:read, settings:objects:write.
• API token (fallback): the resource's own documentation states explicitly — "This resource requires the API token scopes Read settings (settings.read) and Write settings (settings.write)" — confirmed directly against the live v1.100.0 schema doc.
• This module does not touch IAM, Automation, or classic-Config-API-only resources.

• An OAuth client (or platform token, or legacy API token) provisioned with the scopes/permissions above, already bound via an IAM policy (OAuth/platform token path) or token permission grant (API token path).
• A pre-existing Dynatrace alerting profile — created by a terraform-dynatrace-alerting-profile instance in the same or a prior plan — whose id output is passed into this module's profile input. This module does not create or validate the alerting profile.
• A Splunk On-Call (VictorOps) account with a REST endpoint integration configured for Dynatrace, yielding the api_key and routing_key values (Settings -> Integrations -> Rest Endpoint -> Dynatrace, within Splunk On-Call). Source both from your own secrets manager — never as literal values in .tf or .tfvars committed to version control.

terraform-dynatrace-victorops-notification/
├── providers.tf # required_version, required_providers pin — no provider {} block
├── variables.tf # name, profile, api_key, routing_key, message, active — the full contract
├── main.tf # dynatrace_victor_ops_notification.this — thin, total renderer
├── outputs.tf # id, name (api_key/routing_key never output)
├── SCOPE.md # lightweight standalone-module scope (this module's cross-module contract)
├── README.md # this file
└── examples/
 └── quickstart/
 └── main.tf # standalone, directly-runnable Quick Start snippet

module "victorops_notification" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-victorops-notification.git?ref=v1.0.0"

  name        = "victorops-primary-oncall"
  profile     = module.alerting_profile.id # terraform-dynatrace-alerting-profile's `id` output
  api_key     = var.victorops_api_key      # sourced from your own secrets manager
  routing_key = var.victorops_routing_key  # sourced from your own secrets manager
  message     = "{ProblemTitle} - {ProblemImpact} - {ProblemSeverity} - {ProblemURL}"
  # active intentionally omitted — defaults to false (secure-by-default)
}

The caller configures the dynatrace provider (auth and dt_env_url) themselves, outside this module. This module never declares a provider {} block or an auth-related variable.

Consumes

Emits

module "victorops_notification" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-victorops-notification.git?ref=v1.0.0"

  name        = "victorops-staging-check"
  profile     = module.alerting_profile.id
  api_key     = var.victorops_api_key
  routing_key = var.victorops_routing_key
  message     = "{ProblemTitle} - {ProblemURL}"
}

module "victorops_notification" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-victorops-notification.git?ref=v1.0.0"

  name        = "victorops-primary-oncall"
  profile     = module.alerting_profile.id
  api_key     = var.victorops_api_key
  routing_key = var.victorops_routing_key
  message     = "{ProblemTitle} - {ProblemImpact} - {ProblemSeverity} - {ProblemURL}"
  active      = true
}

module "victorops_notification" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-victorops-notification.git?ref=v1.0.0"

  name        = "victorops-detailed-message"
  profile     = module.alerting_profile.id
  api_key     = var.victorops_api_key
  routing_key = var.victorops_routing_key
  message     = <<-EOT
 [{State}] {ProblemTitle}
 Impact: {ProblemImpact} | Severity: {ProblemSeverity}
 Entities: {NamesOfImpactedEntities}
 Details: {ProblemDetailsText}
 Link: {ProblemURL}
 EOT
  active      = true
}

module "victorops_notification" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-victorops-notification.git?ref=v1.0.0"

  name        = "victorops-legacy-profile-link"
  profile     = "b6a8a1b2-9c3d-4e2f-8a1b-1234567890ab" # pre-existing profile, not managed by Terraform
  api_key     = var.victorops_api_key
  routing_key = var.victorops_routing_key
  message     = "{ProblemTitle} - {ProblemURL}"
}

variable "victorops_api_key" {
  type      = string
  sensitive = true
}

variable "victorops_routing_key" {
  type      = string
  sensitive = true
}

module "victorops_notification" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-victorops-notification.git?ref=v1.0.0"

  name        = "victorops-tfc-sourced"
  profile     = module.alerting_profile.id
  api_key     = var.victorops_api_key
  routing_key = var.victorops_routing_key
  message     = "{ProblemTitle} - {ProblemURL}"
}

data "azurerm_key_vault_secret" "victorops_api_key" {
  name         = "victorops-dynatrace-api-key"
  key_vault_id = data.azurerm_key_vault.this.id
}

data "azurerm_key_vault_secret" "victorops_routing_key" {
  name         = "victorops-dynatrace-routing-key"
  key_vault_id = data.azurerm_key_vault.this.id
}

module "victorops_notification" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-victorops-notification.git?ref=v1.0.0"

  name        = "victorops-keyvault-sourced"
  profile     = module.alerting_profile.id
  api_key     = data.azurerm_key_vault_secret.victorops_api_key.value
  routing_key = data.azurerm_key_vault_secret.victorops_routing_key.value
  message     = "{ProblemTitle} - {ProblemURL}"
}

module "victorops_notification" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-victorops-notification.git?ref=v1.0.0"

  name        = "victorops-terse-message"
  profile     = module.alerting_profile.id
  api_key     = var.victorops_api_key
  routing_key = var.victorops_routing_key
  message     = "{ProblemTitle} — {ProblemURL}"
  active      = true
}

locals {
  victorops_teams = {
    platform = {
      routing_key = var.victorops_routing_key_platform
      name        = "victorops-platform-team"
    }
    database = {
      routing_key = var.victorops_routing_key_database
      name        = "victorops-database-team"
    }
  }
}

module "victorops_notification" {
  source   = "git::https://github.com/microsoftexpert/terraform-dynatrace-victorops-notification.git?ref=v1.0.0"
  for_each = local.victorops_teams

  name        = each.value.name
  profile     = module.alerting_profile.id
  api_key     = var.victorops_api_key
  routing_key = each.value.routing_key
  message     = "{ProblemTitle} - {ProblemImpact} - {ProblemURL}"
  active      = true
}

module "victorops_notification" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-victorops-notification.git?ref=v1.0.0"

  name        = "victorops-${var.environment}"
  profile     = module.alerting_profile.id
  api_key     = var.victorops_api_key
  routing_key = var.victorops_routing_key
  message     = "[${upper(var.environment)}] {ProblemTitle} - {ProblemURL}"
  active      = var.environment == "prod"
}

module "management_zone" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-management-zone.git?ref=v1.0.0"

  name = "payments-processing"
}

module "alerting_profile" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-alerting-profile.git?ref=v1.0.0"

  name               = "payments-processing-availability"
  management_zone_id = module.management_zone.id

  rules = {
    availability-payments = {
      severity_level   = "AVAILABILITY"
      include_mode     = "NONE"
      delay_in_minutes = 5
    }
  }
}

module "victorops_notification" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-victorops-notification.git?ref=v1.0.0"

  name        = "victorops-payments-processing"
  profile     = module.alerting_profile.id
  api_key     = var.victorops_api_key
  routing_key = var.victorops_routing_key_payments
  message     = "{ProblemTitle} - {ImpactedEntityNames} - {ProblemURL}"
  active      = true
}

module "victorops_notification_critical" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-victorops-notification.git?ref=v1.0.0"

  name        = "victorops-critical-escalation"
  profile     = module.alerting_profile_critical.id
  api_key     = var.victorops_api_key
  routing_key = var.victorops_routing_key_critical
  message     = "CRITICAL: {ProblemTitle} - {ProblemURL}"
  active      = true
}

module "victorops_notification_warning" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-victorops-notification.git?ref=v1.0.0"

  name        = "victorops-warning-escalation"
  profile     = module.alerting_profile_warning.id
  api_key     = var.victorops_api_key
  routing_key = var.victorops_routing_key_warning
  message     = "WARNING: {ProblemTitle} - {ProblemURL}"
  active      = true
}

module "victorops_notification" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-victorops-notification.git?ref=v1.0.0"

  name        = "victorops-preexisting"
  profile     = module.alerting_profile.id
  api_key     = var.victorops_api_key
  routing_key = var.victorops_routing_key
  message     = "{ProblemTitle} - {ProblemURL}"
  active      = true
}

terraform import 'module.victorops_notification.dynatrace_victor_ops_notification.this' <existing-notification-settings-object-id>

output "victorops_integration_ids" {
  description = "Map of VictorOps notification names to their Dynatrace object IDs, for change-management documentation."
  value = {
    for k, m in module.victorops_notification : k => m.id
  }
}

module "alerting_profile" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-alerting-profile.git?ref=v1.0.0"

  name = "production-availability-critical"

  rules = {
    availability-all-entities = {
      severity_level   = "AVAILABILITY"
      include_mode     = "NONE"
      delay_in_minutes = 5
    }
    errors-tagged-services = {
      severity_level   = "ERRORS"
      include_mode     = "INCLUDE_ANY"
      delay_in_minutes = 10
      tags             = ["env:production", "tier:critical"]
    }
  }
}

module "victorops_notification" {
  source = "git::https://github.com/microsoftexpert/terraform-dynatrace-victorops-notification.git?ref=v1.0.0"

  name        = "victorops-production-critical"
  profile     = module.alerting_profile.id # wires the sibling module's `id` output into `profile`
  api_key     = var.victorops_api_key
  routing_key = var.victorops_routing_key
  message     = "{ProblemTitle} - {ProblemImpact} - {ProblemSeverity} - {ProblemURL}"
  active      = true
}

output "alerting_profile_id" {
  value       = module.alerting_profile.id
  description = "The alerting profile created and consumed by the VictorOps notification below."
}

output "victorops_notification_id" {
  value       = module.victorops_notification.id
  description = "The VictorOps notification configuration wired to the alerting profile above."
}

variable "name" {
  type = string
}

variable "profile" {
  type = string
}

variable "api_key" {
  type      = string
  sensitive = true
}

variable "routing_key" {
  type      = string
  sensitive = true
}

variable "message" {
  type = string
}

variable "active" {
  type    = bool
  default = false
}

api_key and routing_key are never output, regardless of their sensitive = true status at the variable layer — this module omits them from outputs.tf entirely rather than outputting them marked sensitive.

• Total, unconditional renderer. main.tf maps all six variables directly onto dynatrace_victor_ops_notification.this with no try(x, null) guards anywhere. This is possible (and correct, following this module's "thin, total renderer" convention) because five of the six variables have no default — Terraform refuses to plan without a caller-supplied value — and the sixth (active) always carries a concrete, non-null default of false. Nothing reaching the resource block can ever be null.
• Two schema deviations, both documented in variables.tf, both intentional:
• api_key is provider-optional but this module makes it module-required. An apply with no API key would succeed while producing an integration that can never authenticate to Splunk On-Call — an inert, silently-broken channel. Requiring it surfaces that dependency at plan time.
• message is provider-required with no documented default; the module simply passes that requirement through rather than inventing a plausible-sounding default string for free-text content.
• One sensitivity deviation, also intentional: routing_key is not provider-flagged sensitive, but this module marks it sensitive = true anyway, since it is credential-adjacent (it directs alert traffic to a specific escalation group) even though it cannot itself authenticate to an API the way api_key can.
• Implicit reference, not depends_on. profile is wired via module.alerting_profile.id in every example that composes with the sibling module — this gives Terraform a real reference that orders resource creation, consistent with this module suite's convention to respect record ordering via implicit references. No example in this README uses depends_on as a substitute.
• No environment-vs-account-scope split to document. Unlike IAM/Account Management resources, this resource is entirely environment-scoped (Settings 2.0 object against a single Dynatrace environment) — there is no dual-provider-config concern here.
• legacy_id is intentionally invisible. It exists on the live schema as a computed, read-only classic-API cross-reference, but this module does not expose it as an output — no consumer in this catalog needs the REST API v1 equivalent ID.

terraform init -backend=false
terraform validate
terraform fmt -check

Pin the module source at ?ref=v1.0.0 — never an unpinned branch. This library is plan-only: no terraform apply is performed as part of authoring or CI validation; a human applies from a controlled pipeline after reviewing the plan.

• Covered by init -backend=false / validate / fmt -check: type-contract correctness (every required variable enforced at parse time, sensitive flags present, no malformed HCL), provider version constraint satisfiability, and formatting conventions. This is the offline proof gate — it runs with no Dynatrace credentials and touches no live environment.
• Only exercised by a real terraform plan against a configured environment: whether the supplied profile ID actually resolves to an existing alerting profile, whether the supplied api_key / routing_key are accepted by Splunk On-Call at the API level, and whether the caller's OAuth scopes/API token permissions are sufficient. None of this is verifiable offline — this module's static analysis proves the shape of the request, not that Dynatrace or Splunk On-Call will accept it.

$ terraform output

id = "vu9U3hXd3q0AAAABABlidWlsdGluOnByb2JsZW0ubm90aWZpY2F0aW9ucwAGdGVuYW50AAZ0ZW5hbnQAJGNhOTk4YTA3LTVh"
name = "victorops-production-critical"

api_key and routing_key never appear in terraform output — they are omitted from outputs.tf entirely.

• Provider resource reference: dynatrace_victor_ops_notification — Dynatrace Terraform provider docs (dynatrace-oss/dynatrace, subcategory "Notifications").
• Sibling module: terraform-dynatrace-alerting-profile (profile input's source module).
• This module's SCOPE.md (cross-module contract, permissions, prerequisites).

💙 "Infrastructure as Code should be standardized, consistent, and secure."