8.3 Sensitive input/output parameters & Azure Key Vault

Cloud flows routinely handle values that should never appear in plain text inside a run's history — passwords, API keys, personally identifiable data, connection secrets. PL-400 candidates need to know both of the platform's protective mechanisms: masking values in the UI, and keeping secrets out of Dataverse entirely by referencing Azure Key Vault.

Secure Inputs and Secure Outputs

Every trigger and action exposes Settings → Secure Inputs and Secure Outputs toggles. Enabling Secure Inputs masks the values sent into that step in the flow's run history; enabling Secure Outputs masks the values that step returns. Once enabled, anyone viewing a run — including someone with edit access to the flow itself — sees "Content not shown due to security configuration" instead of the actual value.

This is purely a run-history display control: it prevents accidental exposure to people reviewing logs, but it does not change how or where the platform stores the underlying data, and it does not reduce what data the step is allowed to process. A developer should still avoid passing sensitive values through more steps than necessary, and should enable Secure Inputs/Outputs on every action in the chain that touches the sensitive value — masking only the final action leaves the value visible in every earlier step's output.

Azure Key Vault-Backed Environment Variables

Dataverse environment variables (introduced with solution ALM) support a Secret data type. Unlike Text, Number, JSON, or Yes/No variables, a Secret-typed environment variable does not store its value inside a Dataverse table row at all — it stores a reference to a secret held in an Azure Key Vault, and the actual value is resolved from the vault only at the moment a flow, plug-in, or other component requests it.

Setting this up requires:

1. An Azure Key Vault in the same tenant.
2. A Microsoft Entra ID app registration (service principal) with a client secret or certificate.
3. An access policy on the vault granting that app registration Get and List permissions on secrets.
4. Linking the Dataverse environment to the vault (once per environment) so environment variables of type Secret know where to resolve their value.

Referencing Secrets in a Flow

Once configured, a flow retrieves a Key Vault-backed value the same way it retrieves any environment variable — through the environment variable dynamic content — without ever displaying the raw secret in the flow definition. For secrets that live outside the environment-variable model, such as an external service's API key used ad hoc, the flow can call the Azure Key Vault connector directly, using actions like Get secret, to pull a value at runtime rather than hardcoding it into an HTTP action's headers or a connection string.

Why This Matters for ALM

Environment variables and connection references are specifically designed so a solution can move between Dev, Test, and Production without editing flow internals — but a plain-Text environment variable holding a password would export that password inside the solution's XML the moment the solution is exported. Backing sensitive values with Secret-typed environment variables tied to Key Vault keeps the actual credential out of the solution package entirely; only the reference travels with the solution, and each environment's own Key Vault link resolves it locally.

Both mechanisms are complementary, not substitutes: a flow can retrieve a Key Vault secret through an environment variable and still need Secure Outputs enabled on the action that retrieves it, since fetching the secret is itself an action whose output should not appear in plain text in run history.

Rotating a Secret Without Touching the Flow

Because a Secret-typed environment variable stores only a reference to a vault entry rather than the value itself, rotating the underlying credential is a Key Vault operation, not a flow-maintenance task. An administrator updates the secret in Azure Key Vault, and every flow, plug-in, or component that resolves that environment variable picks up the new value on its next run — with no flow to edit, no solution to re-export, and no downtime for the makers who built the automation. This is a meaningful advantage over a Text-typed environment variable holding a password directly, where rotating the credential means editing and republishing the variable's current value in every environment it exists in.

A Common Design Mistake to Avoid

A frequent anti-pattern is pasting an API key straight into an HTTP action's header or a custom connector's connection parameters "just to get it working," then leaving it there. Beyond the security exposure, this couples the credential to a single environment and a single flow definition, defeating the entire purpose of environment variables and connection references for ALM. The exam expects a developer to recognize this pattern as a defect and to redesign it as a Secret environment variable (for a value the platform resolves automatically) or an explicit Get secret call to the Azure Key Vault connector (for a value fetched programmatically at runtime), rather than a value hardcoded into the flow's JSON definition.