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 ephemeralParameters. 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

getEphemeralParameter

Reads an ephemeral parameter for the current Run. Returns undefined if the key wasn’t passed to the Run, or if it has already been invalidated.
This function pauses tracing. Before returning, it calls pauseTracing 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 resumeTracing once you’re done with the value, or the rest of the attempt goes unrecorded.
Parameters
string
required
The top-level key of the ephemeral parameter, as passed in the Run’s ephemeralParameters map.
Returns Returns the value for that key, or undefined if it isn’t available. Values are JSON scalars—string, number, or boolean. Example Scope the whole sensitive section so tracing resumes on its own, even if a step fails:

invalidateEphemeralParameter

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 undefined for that key. See Invalidation and retries.
Parameters
string
required
The top-level key of the ephemeral parameter to delete.
Returns Returns void.

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: