Skip to main content
This feature is in preview. The API may change before general availability. To try it out, contact support@intunedhq.com and we’ll enable it for your workspace.
Read values that were passed to a Run as ephemeral_parameters. Unlike parameters, ephemeral parameters are never stored on the Run record, never sent to sinks, and never appear in logs or traces. They exist only for the lifetime of the Run. Use them for a secret that belongs to a single Run—a portal password supplied by an end user, a one-time code, or a government ID you must not retain.
For how to pass them in and how the platform stores them, see Ephemeral parameters.

Available helpers

Function reference

get_ephemeral_parameter

Reads an ephemeral parameter for the current Run. Returns None if the key wasn’t passed to the Run, or if it has already been invalidated.
This function pauses tracing. Before returning, it calls pause_tracing so the value can’t be captured by the browser trace, a screenshot, or an automation log. It does not resume tracing for you—call resume_tracing once you’re done with the value, or the rest of the attempt goes unrecorded.
Parameters
str
required
The top-level key of the ephemeral parameter, as passed in the Run’s ephemeral_parameters map.
Returns Returns the value for that key, or None if it isn’t available. Values are JSON scalars—str, int, float, or bool. Example Scope the whole sensitive section so tracing resumes on its own, even if a step fails:

invalidate_ephemeral_parameter

Deletes an ephemeral parameter from storage immediately. Call it as soon as the value has done its job. Invalidating a key that doesn’t exist, or that was already invalidated, does nothing.
Invalidation is scoped to the Run, not the attempt, and it cannot be undone. If an attempt invalidates a key and then fails, the retry gets None for that key. See Invalidation and retries.
Parameters
str
required
The top-level key of the ephemeral parameter to delete.
Returns Returns None.

Invalidation and retries

Ephemeral parameters are stored per Run and shared by every attempt of that Run. That makes invalidation a tradeoff:
  • Invalidate early and the value is gone the moment you’re done with it—but a retry can no longer read it, so the retry fails.
  • Don’t invalidate and every attempt can read the value. It’s still deleted automatically when the Run reaches a terminal state, or by its 24-hour TTL if the Run never starts.
Pick based on how the automation is configured: