--- title: "Buttons & Actions" id: "1852" type: "page" slug: "actions" published_at: "2026-09-21T00:21:37+00:00" modified_at: "2026-10-22T16:38:23+00:00" url: "https://xedant.com/agents/portal/docs/actions/" markdown_url: "https://xedant.com/agents/portal/docs/actions.md" excerpt: "A button on a page is not just decoration — it is an action. For…" --- # Buttons & Actions [https://xedant.com/agents/portal/docs/actions/.md](https://xedant.com/agents/portal/docs/actions/.md) A button on a page is not just decoration — it is an action. For every portal button, what happens on click is known in advance. There are six kinds of actions in total, and the agent picks the right one when assembling the page. ## The six kinds of actions - **Link** — opens an external address on the internet. - **A step inside the portal** — opens another page within the portal, without leaving it. - **A request to the agent** — opens the chat with the request already waiting in the input field. - **One click** — hands a ready-made request to the agent as a separate conversation at once, with no dialog and no fields. - **A form** — opens a small window with fields and sends what was entered to the agent. - **Script** — runs a calculating program on the server, and its answer drives the screen. ## Link The simplest action: a click opens the given address — your site, another service, a file to download. When useful, the link opens in a new tab so the visitor does not lose the current portal page. The button label is set by the agent. ## A step inside the portal The button leads to another portal page — for example, from a news card into the news item itself. The address is given as a path inside the portal, and variable values are substituted into it automatically. That is why the same button on a sample page leads to different addresses depending on which page the reader has opened. When needed, the button opens the page in a new tab — the current one then stays where it is: handy when the reader is comparing two pages or does not want to lose what they were reading. Details are in the [Templates & Variables](/agents/portal/docs/templates) section. ## A request to the agent This kind of button spares the reader from typing the same requests over and over. The agent records the needed request in advance, and a click opens the chat panel with the request already in the input field — for example “add the quarterly plan” or “recalculate the estimate from this data”. The reader finishes or corrects the wording and sends it. If the request should go out the moment the button is clicked, that is set explicitly on the button at assembly time. Such a button can also name a skill and a model, and then the chat it opens starts with the wanted guide and the wanted model. The reader’s remembered choice in the chat panel is not affected: the next new chat opens the way they are used to. ## One click The shortest path: one press hands the agent a ready-made request as a separate conversation — no chat panel, no fields and no extra confirmations. The conversation appears in the chat list, its first message is your request, and the agent starts on it right away: there is nothing to switch on and nothing to wait for. That is how buttons are made for familiar repeated jobs: “recalculate the estimate”, “assemble last month’s report”, “check the stock levels”. The button spins while the request is on its way and its neighbours wait. When the agent has accepted the request, a success message appears — its text is set by the agent too, defaulting to “Sent to the agent” — and the configured consequences fire along with it (more on them below). Such a button exists only in the app and only with a connected agent: outside, on the public site, it is never shown. ## A form button When the request needs details from the reader, the button can open a small window with fields. A “Request a report” button, say, asks for the subject and the deadline. The reader fills the fields in and presses Send — the assembled text goes to the agent the same way a form on the page would (see [Forms](/agents/portal/docs/forms) ): as a new conversation in the chat list, and the window closes with a message. A missed required field keeps the window open with a hint and the entered values in place. ## What happens after a task is accepted For a one-click button and for a form that submits to the agent, you can define in advance what happens once the agent has accepted the task: refresh the page data and open the needed page — right there or in a new tab. For example, a “Rebuild the quarterly report” button refreshes the number tiles and opens the report beside the current page. When the task is rejected — the license has expired or the agent is unavailable, say — nothing happens: no refresh, no navigation, only an error message. The refresh can cover the whole page with its live data or only the chosen blocks; “open” understands both a portal page and an ordinary address on the internet. ## Script The most powerful action: a click runs a small program on the server. The program can reach into your system and bring back an answer, and the answer drives the screen. Four reactions are possible: - **a message** — a toast about success, an error or an important remark; - **a refresh of blocks** — one block or the whole page recalculates with the new data; - **a redirect** — another portal page or an external address opens, right there or in a new tab; - **a file download** — the browser receives a file the script assembled. A redirect can land in a new tab as well: the button can ask for that itself, or the script can choose the tab in its answer — the script’s own choice wins when it names one explicitly. When the script returns a human-readable error — “enter a valid email”, say — the reader sees exactly that, not a dry technical message. ## Confirmation before an action For any action except a plain link, a confirmation question can be set: first a question like “Submit the request?” appears, and the action fires only after consent. Useful where a click is hard to undo — submitting a form or a request, for example. ## How many buttons fit A block holds up to three buttons — if the agent adds more, the structure check warns it about that. A carousel can have its own buttons on every slide: “Read” on the first slide, “Sign up” on the second. The same buttons can be put into table cells, so a row can carry its own “Open” or “Request” button. More about checks is in the [Page Validation](/agents/portal/docs/validation) section. ## There are no dead buttons A button appears on the page only when its handler exists. If a button points to a script that is not there, it simply does not render. Request buttons — a request to the agent, one click and a form button — do not appear without a connected agent and on the public site: there is nobody to hand the request to. The reader never stumbles onto an element that does nothing. ## Commit and Undo in the header The agent keeps its edits in the repository’s working folder — like a draft before it is written into the history. While that folder holds uncommitted changes, a pair of buttons appears in the portal’s header: **Commit** stages, commits and pushes the work and marks the success, while **Undo** asks first and then irreversibly discards every uncommitted change. The pair checks its status every 15 seconds and disappears once the working folder is clean. Both buttons are locked while either operation is running. Git is driven by the agent: the portal itself runs no git commands. Next: what can be substituted into a redirect path — in the [Templates & Variables](/agents/portal/docs/templates) section; how forms with submission work — in [Forms](/agents/portal/docs/forms) ; how data for an action is computed — in [Scripts & Dependencies](/agents/portal/docs/scripts) . [← Back to the documentation index](/agents/portal/docs)