Selector node

A Selector node writes a value to a stored Key Selector while a workflow executes. Its main use is a dedicated scheduled refresh flow that keeps a shared service token current.

Use a dedicated refresh flow#

Scheduled refresh action
    → Request service token
    → Extract token
    → Selector saves shared token
    → End

Business action
    → Read shared token
    → Call service

Configure the selector name, controller or global scope, and body template. The body can reference the preceding node, for example ${ExtractToken}. Use an appropriate secret type for a sensitive shared value.

Keep request-local values in the session#

For a user-facing request that logs in to a service and immediately calls it, use the login result directly:

Login Request → ExtractToken Function → Business Request

The Business Request can use Bearer ${ExtractToken}. A Selector node between these steps would persist data unnecessarily and can mix concurrent users' tokens. Cloudgate's workflow validation also rejects the unsupported authentication-to-selector-to-business pattern.

Configure static values without a node#

To store a manually supplied URL, key, or configuration value, use Workflows → Key Selectors. Creating a stored selector does not require adding a runtime node to every workflow that reads it.

Sandbox and production values are configured separately. Verify the scheduled refresh action's environment and intended destination before enabling it.

Test the lifecycle#

Use a test service account, run the refresh action, and confirm the business action reads the expected value. Check what happens if refresh fails or the token expires before the next run. Do not log the token to prove the refresh succeeded; use status, expiry metadata, or a harmless authenticated service call.