Put the triggers, conditions and actions people reach for first at the top of the add dialog #258

Problem statement

When people add a trigger, condition or action, the "By type" list in the add dialog shows each category in A-Z order. The items people need most land wherever the alphabet puts them. In Sun, Sunrise and Sunset sit below options few automations use. In Light, "Turn on" is mixed in with every other light action. In mixed categories like Air quality, "Gas detected" comes before "Carbon monoxide detected", even in a home that only has a carbon monoxide sensor.

This affects everyone who builds automations, and new users the most: they have to scan a whole category to find the one obvious choice. It started with the Sun trigger, but the same problem exists in trigger, condition and action categories. Solving it serves #7 Make Home Assistant More Approachable, whose stretch goal asks for common tasks to be discoverable without deep technical knowledge.

Community signals

• Internal discussion between design and product (Oct 14, 2026). Today there is no UI pattern at all for bringing items up.
• No analytics on which items people pick. Long term, that is the data that should drive the list.

Scope & Boundaries

In scope

• A "Suggested first" sort in the "By type" list of the add trigger, condition and action dialog, next to "Name (A-Z)"
• Items that work with entities the user has come first in their category, worked out from what each item declares it targets
• A hand-picked list of the items that lead their category, limited to what ships with Home Assistant
• A divider between suggested items and the rest of the category
• Shipping it as a Labs feature, with "Suggested first" as the default sort while the feature is on
• Growing the hand-picked list in iterations, from feedback

Not in scope

• The "By target" view. Picking a target already narrows it to what applies, so that view stays A-Z.
• Hand-picked suggestions for custom integrations. They only move up when they match the user's entities. Letting integrations declare their own leaders is a later step.
• Usage analytics. This opportunity doesn't depend on them, but they are the natural next source for the list.
• Ordering by an LLM or another decision model

Foreseen solution

The sort control above the "By type" list gets "Suggested first" and "Name (A-Z)". With "Suggested first", each category is ordered like this:

1. Items that apply to the user's devices, where a category mixes device types. In Air quality, with a carbon monoxide sensor and no gas sensor, the carbon monoxide items come first.
2. Within those, the hand-picked items lead (Sunrise and Sunset in Sun, "Turn on" in Light). Only built-in items can be on this list.
3. A divider, then everything else A-Z.

The order is deterministic. It uses only the user's entities, a fixed list we publish, and the user's language for A-Z. It doesn't track behavior or guess. The order changes when devices are added or removed, or when the list changes in a release.

The hand-picked list follows a rule rather than taste: the main event or verb of a category, at most 2–3 items per category. "Detected" and "cleared" items go together.

Which items go on the hand-picked list is still to be decided.

Risks & open questions

• Feedback is likely to conflict, because everyone expects their commonly used items on top. The plan is to wait for a usage curve to emerge from the feedback and take only the top choices. Is that enough of a signal without analytics?
• If a category's order doesn't change at all, "Suggested first" looks like it does nothing. Should the sort control be hidden or disabled for categories it doesn't affect?
• Each iteration would ask users "Is the current Suggested first sorting useful for you?". Where do we ask it: in Labs or on Discord?
• Who decides the first version of the hand-picked list, and with whose input beyond design and product?
• When does this leave Labs? What does "complete enough" mean for the list?
• When do we commit to analytics, so the list is based on usage and not on what people say they use?
• Naming: "Common first" promised something we don't measure, so it was renamed to "Suggested first". Does that name hold up with users?

Appetite

Small. The sort is a contained frontend change. Most of the effort goes into deciding the list and gathering feedback over a few iterations.

Execution issues

No response

Decision log