Prerequisites

To better understand this article, learn about Dynamic Parameters here.

Overview

Dynamic Parameters are temporary variables used within chatbot flows that are unique for each flow. They are invisible in the UI, so the agents can’t see them.

Whereas Dynamic Fields, on the other hand, are visible and persistent, and they can be accessed via the API, functions, or included in flows. Fields can also be user-editable, unless you explicitly make them read-only.

Even if you hide them in the UI, they still exist in the background. For example, when you fetch a ticket via the API, you’ll always receive all 10 dynamic fields, whether they’re enabled in the UI or not. This is how Dynamic Fields look in the response body:

How are Dynamic Parameters Different from Dynamic Fields?

Dynamic Fields and Parameters behave similarly which is, both can hold values and be used in chatbot flows. The difference is in visibility and scope.

Dynamic Parameters:

Store the information temporarily and only exist inside chatbot flows.
They’re invisible to agents, and they don’t persist once the flow ends.
They’re mainly used for behind-the-scenes logic, like storing API responses, checking conditions, or passing values between flows. For example, has this person reached out in the last 10 days?
There can be any number of parameters, but they never appear in the UI.

Dynamic Fields, on the other hand:

The stored information is accessible and editable across different parts of the system, not only in chatbot flows.
Once enabled, they appear everywhere a ticket appears: in the UI, the API, chatbot flows, and chat widgets, which means agents can see and interact with them, and developers can pre-fill them using JavaScript.
In other words, fields are not just internal variables; they’re part of the ticket data model, accessible both to agents, developers, and systems (API, flows, widget).

Note - Dynamic fields are capped at ten because they are always included in the API response, and having too many would create unnecessary overhead with each call.

How Agents Use Dynamic Fields

For agents, dynamic fields provide visibility into ticket-specific data that has been collected automatically or entered by other users. When an agent opens a ticket, they might encounter fields pre-populated by a chatbot, for example, the ticket subject, user account ID, or conversation status. These fields help agents understand the history and context of the ticket before engaging with the user.

Agents can edit fields that are enabled for them, adding notes or updating information as needed. However, some fields may be read-only if they have been configured by admins to prevent accidental changes to critical data.

Agents also benefit from dynamic fields in workflows where multiple automated steps occur before human interaction.

For example, a chatbot might pre-fill several fields based on user input or system checks, such as conversation satisfaction or whether it's a VIP account. When the ticket reaches an agent, they can immediately see all relevant information without needing to ask the user again.

How Admins Use Dynamic Fields

🚧
Note:
Only admins can see this page. Agents can skip this section.

To configure Dynamic Fields, go to Settings, then click on Conversations under General Settings and select Dynamic Fields to see the page below:

You can enable or disable a field to be visible in the UI by sliding the slider beside the field. You can also configure the fields to be read-only by checking the box beside the field.

Here’s how an example ticket might use dynamic fields in action: ● Field 1 (Subject): Filled in automatically by the chatbot or provided by the user. ● Field 2 (User Account ID): Collected from the user and stored as read-only so agents can’t alter it. ● Field 3 (Conversation Status): Captures whether the user said the chatbot was helpful or unhelpful, which is collected by the bot, not editable by the agent. ● Field 4 (Agent Notes): Left open for agents to edit and add their own information. ● Field 9 (Incoming Email): Automatically populated by a function when the ticket is opened, but editable in case agents need to fix the data.

How Developers Use Dynamic Fields

Developers use fields mainly via functions and API calls.

Automations can populate/update fields on events (e.g., new ticket, status change, new message).
Useful for integrations, analytics, and system-wide automation.

Functions

Functions connect events to Glassix actions without external endpoints.
Populate or update fields based on events.
Run independently, unlike chatbot flows.

Common use case: A VIP checker function verifies user status and updates the field with “VIP” or “Not VIP.”

Adding a Function

Click Add+.
Enter the function name.
Choose an event (e.g., NEW_MESSAGE).
Select the function action (e.g., add incoming email address).
Click Save.

To delete a function, click the dustbin icon next to it.

FAQs

Q. Why can’t I edit this field? A. It is read-only. Only admins can configure edit permissions.

Q. Why is this field always called “Subject”? A. The first dynamic field is reserved as the ticket subject.

Q. Why is field three always filled in with phone/email? A. Certain fields are auto-populated by chatbots, functions, or integrations.

Q. Why do I see a different number of fields in departments? A. Admins can enable/disable fields per department.

Q. Can I use dynamic fields to track a value across tickets/contacts? A. No, fields are ticket-specific. Use an external system for cross-ticket tracking.

Q. Can dynamic fields be populated by functions? A. Yes. Functions can automatically update fields on ticket events.

Q. Are dynamic fields accessible via the API? A. Yes. All fields are included in API responses, visible or not.

Q. Can dynamic fields be passed through chat widgets? A. Yes. Fields can be populated via widgets or JSON Web Tokens (JWT).

Q. Is there a rate limit when setting fields? A. API calls are rate-limited (60–90/min). Using server-generated ID tokens bypasses limits.