Dataverse Config Change to PR for Audit

Overview

This flow converts Dataverse environment variable changes into reviewable GitHub activity. Whenever the value column of any environmentvariablevalue row changes — i.e., an admin updates a configuration value in the maker portal or via the admin app — the flow fetches the full context for the change (schema name, display name, variable type, new value, definition/value IDs, modifier) and pushes a repository_dispatch event to a config repository on GitHub. A GitHub Actions workflow on the receiving side can then write the new value to the tracked config file and open a pull request so every env-variable change has a reviewable, merge-able audit trail.

Use Case

Teams that use Dataverse environment variables to hold runtime configuration (API endpoints, feature flags, tenant switches, repo owners/names) often lose the "who changed what, when, and why" audit trail the moment the value leaves their GitOps pipeline. This flow closes that gap without changing how admins edit values. The resulting PR is the audit artifact: reviewers see diff, approver, merge commit SHA, and a linkable URL tied back to the Dataverse change.

The flow is ideal for teams that:

• An admin updates an environment variable value in the usual Dataverse admin UI (Environment Variable Values app, or inline via solution).
• The flow fires on the Update message of environmentvariablevalue with filteringattributes = value, so it only runs when the stored value actually changed (not every metadata touch).
• It enriches the event with the definition row (schema name, type, display name) and dispatches a repository_dispatch event to a GitHub config repo, carrying a structured client_payload that a workflow can turn into a commit + PR.
• The resulting PR is the audit artifact: reviewers see diff, approver, merge commit SHA, and a linkable URL tied back to the Dataverse change.

Flow Architecture

Environment Variables

Connectors & Connections

Note — All connections are referenced as solution connection references; the flow is portable between environments as long as a connection is mapped at import time.

Customization Guide

Almost every realistic variant of this flow can be implemented by changing environment variable values. A few cases require small edits inside the flow definition — those are called out explicitly below.

Point at your own config repo

In the target environment, set the three environment variable values: flowlibs_GitHubConfigRepoOwner, flowlibs_GitHubConfigRepoName, flowlibs_ConfigChangeEventType. No flow edits are required.

Add the receiving GitHub Actions workflow

In your config repo, add a workflow with on: repository_dispatch: types: [<your event type>] that reads github.event.client_payload, writes the new value to the tracked file (e.g., config/env-variables.json), commits on a branch like dataverse/update-<schema_name>-<yyyyMMddHHmmss>, and opens a PR with the payload metadata in the body.

Narrow which variables audit

If you only want a subset of variables audited, add a Condition after the Definition lookup that checks schemaname starts with a prefix or is in a list, and route non-matches to a Terminate (Succeeded).

Filter out empty-string updates

For variables that admins sometimes blank out intentionally, add an empty(...) check on new_value and skip dispatch so the config repo doesn't get churn commits.

Switch to signed commits / app-authored PRs

The built-in GitHub connector commits as the OAuth user. If you need commits authored by a bot identity, replace the final action with a GitHub App token flow (still using CreateRepositoryDispatchEvent) — the downstream workflow in the config repo can use actions/create-github-app-token to author the PR.

Turn it on

The flow ships with state = Stopped by design. Start it from the designer or via POST /flows/{id}/start after the environment variable values are set and the receiving workflow is in place.

Key Expressions

The flow is intentionally light on Power Fx / WDL gymnastics — the heaviest expressions are the branch-name concatenation and the approval outcome check. They are listed below in the order they appear in the flow.

@triggerOutputs()?['body/environmentvariablevalueid']

@outputs('Get_Env_Variable_Value_Row')?['body/_environmentvariabledefinitionid_value']

@outputs('Get_Env_Variable_Definition_Row')?['body/schemaname']

@outputs('Get_Env_Variable_Definition_Row')?['body/displayname']

@outputs('Get_Env_Variable_Definition_Row')?['body/type']

@outputs('Get_Env_Variable_Value_Row')?['body/value']

@outputs('Get_Env_Variable_Value_Row')?['body/_modifiedby_value']

@outputs('Get_Env_Variable_Value_Row')?['body/modifiedon']