chatbot_triggering_answers_widget

A chatbot script is a sequence of steps, and a step can be made conditional on how the visitor answered an earlier question. Choosing those triggering answers means picking from the answers defined elsewhere in the same script, and only that script: answers from an unrelated chatbot would be meaningless.

The filtering itself is server side, driven by a domain that reads a key from the context. This widget's job is to put that key there. When it starts, it writes the current script's identifier into the user's context, and from then on the answer search is narrowed.

Nothing else about the field changes. The tags, the dropdown and the creation behavior all come from the tags widget it extends.

Chatbot scripts get long, and a picker offering every answer in the database rather than the eight in front of you turns a two second choice into a hunt. This is a small filter with a real effect on how usable the builder is.

The mechanism, though, is worth understanding before copying it. Writing into the user context to pass a filter is effective and blunt: the entry is not scoped to the field or the view, so it stays for the session and applies wherever that key is read. In a single-purpose builder screen that is acceptable; as a general pattern it is not, and passing a domain or a context on the field is the cleaner route.

The other thing to note is that this screen changes in the next version. The widget is gone from the development branch, which suggests the filtering has been reworked rather than removed, but any customization of the step form should be re-checked before that upgrade.

The core usage

<field name="triggering_answer_ids"
       widget="chatbot_triggering_answers_widget"/>

No options. The narrowing happens through the context the widget writes when it starts.

What it writes

# into the user's context, once, at startup
force_domain_chatbot_script_id: <the script's id>

Only when the script has already been saved; a new script has no id to write.

The plain tags widget

<field name="triggering_answer_ids"
       widget="many2many_tags"/>

Same appearance, but the dropdown offers answers from every chatbot script.

The widget is a dozen lines. Its initialization calls the parent's and then, if the form's root record has a database id, updates the user's context with a key naming that script. A comment above it states the purpose exactly: force the script being edited into the context so triggering answers can be filtered to steps of that script.

Three consequences follow, and all three are worth weighing before reusing the approach.

The write happens once at startup, so opening a different script in the same session overwrites the key rather than adding to it. That is fine for a form where only one script is open at a time.

The guard on the record id means a brand new, unsaved script never writes the key, so the answer list is unfiltered until the script is saved. On a new script there are no answers to offer anyway, so this rarely shows.

And the context is the user's, not the field's. Nothing clears it when the widget is destroyed, so the key remains for the rest of the session. Anything else reading that key would see it, which is why this is a pattern to recognize rather than to adopt.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and this may still change; we re-verify the page after release.

The widget is gone. There is no registration under this name on the development branch, and the file is absent from the module. The chatbot builder has been reworked around it.

Because an unknown widget name falls back to the field's type, a custom view still naming it would render plain tags with no filtering at all, offering answers from every script. Search custom livechat views for this name before upgrading.