Key Vault as Connection-Secret Source
A reusable child flow fetches secrets (API keys, connection strings) from Key Vault at runtime and returns them to parent flows after allow-list checks, so no secret is stored in flow definitions or environment variables in plaintext. Centralizes governed secret retrieval for all automations.
Provided as-is, without warranty of any kind. Review and test each pattern in a non-production environment before deploying it to live automations. See our Terms.
Overview
This is a reusable child flow that centralizes secret retrieval for every FlowLibs automation. A parent flow calls it with a caller identity and a secret name; the flow authorizes the request against two allowlists, fetches the value from Azure Key Vault at runtime, writes an audit row to Dataverse, and returns the secret to the caller. No secret value is ever stored in a flow definition or an environment variable in plaintext.
Why it matters: secrets hardcoded in flows or kept in plain environment variables leak through exports and run history. A single governed retrieval pattern keeps every secret in Key Vault, enforces who may fetch what, and produces a tamper-evident audit trail.
Ships Off (Stopped). In production, mark the response output secure so the value is not logged in run history.
Use Case
Many flows need API keys or connection strings (e.g. to call a third-party REST API). Instead of each flow storing its own secret, they call this one child flow over HTTP. It confirms the caller and the requested secret are both allow-listed, retrieves the value from Key Vault only when both checks pass, and logs every request - authorized or denied - with the secret name only (never the value).
Flow Architecture
When an HTTP Request Is Received
Request (HTTP)Accepts JSON body {caller, secretName} (both required).
Initialize Trace & Config
Initialize variableMints a correlation id and binds the caller, requested secret, vault, and the caller + secret-name allowlists.
Authorization Gate
ConditionProceeds only if the caller is allow-listed AND the requested secret is allow-listed.
Get Secret (authorized)
Key Vault - GetSecretFetches the value at runtime; it never lives in the flow definition.
Audit + Respond (authorized)
Dataverse CreateRecord + Response 200Writes an Authorized audit row (name only) and returns {status, secretName, secretValue, correlationId}.
Audit + Deny (unauthorized)
Dataverse CreateRecord + Response 403Writes a Denied audit row (no Key Vault call) and returns {status: denied, reason, correlationId}.
Environment Variables
| Schema name | Type | Default | Description |
|---|---|---|---|
| flowlibs_VaultName | String | kv-flowlibs-demo | Key Vault name backing the connection (documentation/portability). |
| flowlibs_AllowedCallers | String | ["FlowLibs-DemoParentFlow","FlowLibs-Orchestrator"] | JSON allowlist of caller identities permitted to request secrets. |
| flowlibs_SecretNameAllowlist | String | ["demo-api-key","sample-connection-string"] | JSON allowlist of secret names this flow may fetch. |
Connectors & Connections
| Connector | API name | Actions used |
|---|---|---|
| HTTP | request | manual (HTTP request trigger) Response |
| Azure Key Vault | shared_keyvault | GetSecret |
| Microsoft Dataverse | shared_commondataserviceforapps | CreateRecord |
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.
- Wire up a parent flow
- Call this flow's HTTP trigger with {caller, secretName}; read secretValue from the response.
- Expand the allowlists
- Add caller identities to flowlibs_AllowedCallers and secret names to flowlibs_SecretNameAllowlist.
- Secret versioning
- Swap GetSecret for GetSecretVersion to pin a specific version.
- Harden the response
- Mark the Response output secure; optionally return a reference/handle rather than the raw value.
- Alerting
- Add a Teams/Outlook notification in the Denied branch for security review.
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.
EXPR.01Authorization
Both allowlists must pass.
EXPR.02Secret value
Returned to the caller (mark secure in production).
EXPR.03Trigger fields
Caller identity and requested secret.
EXPR.04Correlation id
Traces the request across the audit row and response.
Comments
Sign in to join the conversation.
Sign inNo comments yet. Be the first to share your experience with this flow.