--- title: "Forms" id: "1859" type: "page" slug: "forms" published_at: "2026-09-21T00:25:46+00:00" modified_at: "2026-10-22T16:38:23+00:00" url: "https://xedant.com/agents/portal/docs/forms/" markdown_url: "https://xedant.com/agents/portal/docs/forms.md" excerpt: "A form is a way to get something from the reader: a news subscription, a…" --- # Forms [https://xedant.com/agents/portal/docs/forms/.md](https://xedant.com/agents/portal/docs/forms/.md) A form is a way to get something from the reader: a news subscription, a request, a callback order. The reader fills in the fields and presses the button, and then the submission goes by one of two addresses. Most often it is a calculating script: it accepts the data, does something with it and answers the page. It can be the agent instead: the form sends the assembled request to it, and the agent takes the work on (see [Chat with the AI Agent](/agents/portal/docs/agent) ). ## Form fields A form is assembled from fields of different types: - **Text** — one line: a name, a company, the subject of a request. - **Number** — digits only: a quantity, an amount, a year. - **Email** — an email address with a format check. - **Password** — typed with hidden characters. - **Multi-line text** — for comments and descriptions. - **A choice from a list** — the reader picks one option from ready ones. - **Checkbox** — a consent or a confirmation: “I agree to data processing”, for example. - **Date** — a date picked from a calendar. - **Hidden field** — invisible to the reader, but its value travels with the submission. That is how service marks are added to a form: where the request came from, which page it was. ## The check before sending Required fields are checked before submission, right in the browser. When something is missing or the email is typed wrong, the reader sees a hint and stays in place — the entered values are not lost. A checkbox is required only when it is marked as such. ## What the script’s answer does After submission the script can answer the page in different ways: - **a message** — a toast: about success, an error, or information; - **a refresh of blocks** — part of the page recomputes with the new data; a subscriber counter grows, for example; - **a redirect** — another portal page or an external address opens, a thank-you page say — right there or in a new tab; - **a file download** — the reader at once receives a file the script assembled. ## When the script returns a soft error Sometimes the data is formally filled in but does not fit: that email is already subscribed, or the code does not exist. In that case the script returns a soft error, and its text shows right under the form — the reader sees what to fix, and every entered value stays in place. The form does not have to be typed again. ## A form that sends to the agent Such a form is convenient where the handling cannot be described in advance: a request for a change, a message to support, an idea from a staff member. The agent writes the request template beforehand, with places for the reader’s answers, and after submission the portal opens a separate conversation with the agent: its first message is the assembled request, and the conversation is visible in the chat list. The chat panel does not slide out — the reader stays on the page and keeps working. It is the same order as a form button on a page. - **The answers land in the text** — the agent sees the filled fields and where the request came from: which page was open and which button was pressed. - **The request goes as a separate conversation** — it appears in the chat list, and the agent’s answer is visible right there; the chat panel does not slide out over the page. That is convenient: the work does not distract the reader, and the conversation can always be opened and continued. - **Success is visible at once** — once the agent has accepted the request, the reader sees “Form sent”, and the form clears and is ready for the next one. - **After acceptance the page may refresh** — besides the submission, the form can be given consequences: refresh the numbers on the page and open a portal page or an external address, right there or in a new tab. When the request does not go through, nothing fires. - **A failure keeps what was entered** — if the agent is unreachable or the task did not go through, the values stay in the fields and the error shows right under the form: one can retry without typing anything again. - **It also works as a button** — when a form filling the page is too much, the agent can make a button that opens the same window with fields (see [Buttons & Actions](/agents/portal/docs/actions) ). ## Confirmation and double-click protection A confirmation question can be set before submission — “Submit the request?”, for example. While the submission is in flight, the button shows that work is going on and cannot be pressed again: no double request will go out. The public site also has the shared protection from frequent submissions — at most ten per minute from one address. ## Example: a news subscription The demonstration portal has a subscription form: name and email. After submission a success message appears, and the subscriber-counter block on the same page refreshes and shows the new number. The form clears and is ready for the next subscription. That is the full working circle: filled in — sent — saw the result on the page. Next: how the agent edits content — in the [Agent Management](/agents/portal/docs/management) section; how a form’s data is computed — in [Scripts & Dependencies](/agents/portal/docs/scripts) ; what other buttons exist — in the [Buttons & Actions](/agents/portal/docs/actions) section; how to open a form to the outside — in [Public Site](/agents/portal/docs/public-site) . [← Back to the documentation index](/agents/portal/docs)