← All posts

Loading Workflow Configuration Safely with Temporal

Michael Read · Sep 25, 2026 · 2 min read

I made a common Temporal mistake — and it's worth learning from.

Workflows need config — polling intervals, batch sizes, timeouts. The natural instinct is to read from a properties file, just like any other application. But in Temporal, that instinct will break your system.

Here's why: workflows must be deterministic. During recovery or replay, Temporal re-executes your workflow code. If a configuration file changes between the original run and the replay, the re-executed workflow gets different values. Result? A non-determinism error, or worse — inconsistent behavior you can't easily diagnose.

I made this mistake in my previous post (now corrected). My workflow constructor was loading config directly from app.properties:

// ⚠️ The mistake I made: reading config directly in the workflow constructor
public UserEntityWorkflowImpl() {
    this.pollingInterval = Integer.parseInt(properties.getProperty("polling.interval", "1000"));
    this.maxEvents = Integer.parseInt(properties.getProperty("max.events", "50"));
}

This works in happy-path testing. But it creates a hidden trap: a configuration change halfway through an active workflow's lifecycle could cause replays to behave differently than original executions.

The fix: load config via an Activity

Activities run outside the determinism sandbox. When an Activity returns a result, that result is recorded in the workflow history. During any subsequent replay or recovery, Temporal reuses the recorded result rather than re-executing the Activity. The configuration values are locked in, exactly the same as they were the first time.

You can see how I implement the configuration Activity here: LocalConfigActivitiesImpl.java

And the workflow calls it at startup:

@Override
public String create(UserInput input) {
    // Get configuration from Activity - result is recorded and deterministic
    config = localConfigActivities.getEntityConfig();
    // Now config.pollingInterval and config.maxEvents are safe to use
    ...
}

This small shift is a good example of why the Temporal determinism constraint, while it feels like a limitation at first, actually forces better design decisions that make systems more reliable.