Define dataflows for saas-integrations-owned integrations

[philjlee]

Jira: TXP-277

Adds assets/dataflows.yaml to 1 integration owned by @DataDog/saas-integrations, declaring 1 dataflow. Mechanical change: no code, no metrics, no manifests touched.

Precedent: #2925 "Define dataflows for saas-integrations", which created 13 of the 14 existing dataflow files in this repo.

Selection criteria

A directory is in this batch only if all of the following hold:

1. It has no assets/dataflows.yaml today.
2. It has a parseable manifest.json. The dataflows validator hard-requires one — dataflows_validation_handler.go:56.
3. The correct data_type is mechanically derivable from a committed artifact, with no judgement call:
   • metadata.csv with at least one data row → metrics
   • a log pipeline under assets/logs/*.yaml → logs
   • both → both entries
4. .github/CODEOWNERS resolves <dir>/assets/dataflows.yaml (last-match-wins) to an owner set containing @DataDog/saas-integrations.

yugabytedb_managed/ has @DataDog/saas-integrations as a Datadog team CODEOWNER (co-owned with @DataDog/ecosystems-review; grouped here since it's the more specific/smaller of the two teams), so review from @DataDog/saas-integrations covers this PR.

Field values

provides:
  - id: <app_id>-<data_type>
    always_on: true
    granular: false
    data_type: <metrics|logs>
    direction: inbound

always_on: true / granular: false / direction: inbound matches 14 of the 17 dataflow entries already in the repo. The only deviation in the repo is vercel, which is always_on: false for a Serverless product-enablement reason that does not apply here.

The dataflow ID is <app_id>-<data_type>, taking app_id from manifest.json rather than the directory name. It was checked for collisions against every existing ID in the repo.

Validation

This file was validated by executing the real validator, DataflowsValidationHandler from dd-source/domains/integrationscatalog/libs/catalogassetslib/dataflows_validation_handler.go, at ddoghq/dd-source@main, against every dataflows.yaml file in the repo working tree with this PR applied. Result: 0 failures, covering per-file unmarshalling, proto constraint validation, and the cross-file HandleLibrary ID-uniqueness check.

The harness was negative-tested first and confirmed to reject: a missing always_on; a data_type outside validDataTypes; an id breaking ^[a-z0-9-]+$; an id under 3 characters; a file with neither provides nor uses; a .yml extension; a missing manifest.json; and the same dataflow ID provided by two apps.

This matters because APW does not post validator comments on integrations-extras PRs (enable_validator_comments is set only for pub-platform-staging and publishing-platform). A malformed dataflows.yaml merges cleanly here and only fails afterwards, in the shared asset pipeline.

Contents

Metrics only (1)

Integration	Dataflow IDs
yugabytedb_managed	yugabytedb-managed-metrics

🤖 Generated with Claude Code

[datadog-datadog-prod-us1-2]

More details

The added YugabyteDB Managed dataflow accurately describes the integration's metrics-only inbound export and matches the repository's established dataflow conventions. Executable YAML validation covered the candidate, all 15 repository fixtures, and five malformed-shape cases; the repository's ddev validator could not run because ddev is not installed in the sandbox.

Was this helpful? React 👍 or 👎

_{📊 Validated against 21 scenarios · Open Bits AI session}

_{🤖 Datadog Autotest · Commit e9248d8 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest}