Home Assistant has started retiring limited templates, the restricted kind that cannot read entity states, the current time or the variables of a run. Franck Nijhof (frenck) is removing them field by field. The first two fields went into the development branch on 19 October 2026 at 03:45 Polish time, merged by Paulus Schoutsen (balloob): the enabled option of a step in a script or automation, and the webhook_id of the webhook trigger. Both changes are set for Home Assistant 2026.11.

enabled is checked when the step runs

Until now, enabled on a step could be a limited template, rendered without any variables. If it referred to one, Home Assistant skipped the step or stopped the run with an error. The option is rendered each time the step is about to run anyway, so the restriction protected nothing. It is now a regular template that can use states(), now(), trigger, this and values from the variables section. If the result is false, the step is skipped. If the template cannot be rendered, the run stops with an error.

So a step can now depend on a helper's state:

actions:
  - action: light.turn_on
    enabled: "{{ is_state('input_boolean.guest_mode', 'off') }}"
    target:
      entity_id: light.hallway

The change also fixes a bug. A condition placed as a step of its own rendered enabled a second time, as a limited template without variables. An enabled based on a variable came out undefined there, and the run stopped. That second render is gone.

Not everything has moved yet. The enabled option of conditions under conditions: and inside if, choose and repeat, the enabled option of triggers and trigger_variables stay limited for now. The pull request says they will follow in separate changes. In a blueprint, the documentation still recommends setting enabled directly to an !input with a boolean selector, not through a template.

webhook_id with states and hashes

The webhook trigger's webhook_id can now use states, registry helpers such as device_attr and area_name, and hash functions. The pull request says this is handy for building webhook IDs in blueprints. When the ID is rendered does not change. It happens once, when the trigger is set up: the automation loads, is reloaded or is turned on. A later state change does not move the webhook to a new address. In a "Wait for a trigger" step the ID is rendered each time the wait starts, with the variables of the run. Existing configurations keep working and are evaluated at the same moment as before.

The documentation for webhook_id was merged into the next branch of home-assistant.io the same night. The documentation for the step enabled change (#49387) was still under review on the evening of 19 October.