On a single-page form one button does both jobs: it is where the answer is generated, and it is where the ticket is filed. The deflector watches it for both, and the deflection rate is correct with no extra configuration. A multi-step form splits those jobs across two buttons — the reader describes the problem on step 1 and confirms on step 2 — and the deflector watching only the first one never sees the submission. Every deflection is then recorded as a success, and the rate reads 100% forever.

​
The two selectors

In the dashboard these are Submit element (Form wiring) and Ticket-submitted element (Form wiring).
1

Intercept the earliest point the question is complete

Usually the “Next” button on the step carrying the description. Intercepting later means the reader has filled in three more screens before being shown an answer that makes all of it unnecessary.
2

Track the failure at the last point

The button that actually creates the ticket. This is what the deflection rate counts against.

​
Which event

Multi-step forms are almost always onClick. A step transition is a click handler, not a form submission — there is frequently no <form> element involved at all until the final step, and sometimes not even then. If you are unsure, set data-debug-mode="true" and press the button. The console prints whether the deflector attached and on which event.

​
When the form is rebuilt between steps

Some multi-step forms unmount step 1 entirely when moving to step 2, which means the ticket-submitted element does not exist when the deflector attaches and the listener is never bound. Two options:
  • Point the failure selector at something stable — a container that survives the transition, using event delegation. The deflector listens in the capture phase, so a selector on an ancestor of the final button still sees the click.
  • Re-arm on the transition: set data-render-on-load="false" and call window.BeforeQueryFormDeflector.render() when the step changes. See Rendering manually.

​
Verifying the rate is honest

File a ticket through the whole flow after reading an answer, then check Activity on the deflector. You should see the interception counted under Filed anyway, not Tickets avoided. If it lands under “avoided”, the failure selector is not matching — which is exactly the failure mode this page exists to prevent, and the only way to catch it is to file one ticket on purpose.
Do not set the failure selector to the same element as the submit element on a multi-step form. It is the default, it is correct on a single-page form, and on a multi-step one it produces a number that is confidently wrong rather than obviously missing.