Whatever business scenario a kiosk is built for, it's ultimately assembled from a small set of basic elements, added, configured, and connected together in different ways. Those elements are Screen, Decision, and Action, along with supporting concepts like Loops, Data, Merge Fields, and Queries covered further down this article.

Screen

A screen presents the user with display text, fields, CRM data, data collected from earlier screens, and buttons for choosing the next step. Each button represents a branch in the kiosk's flow, and anything entered into a screen's fields, or pulled in from the CRM, becomes available for use in later screens.

Display elements

• Text. Displays plain text to the user, useful for instructions, warnings, feedback, highlighting the importance of certain fields, or pointing users to who to contact.
• Queries. Lets a kiosk retrieve data using an API or COQL, including from third-party services, giving users access to relevant data and automated responses. Queries can be used in Screen and Decision components.
• KioskRecords. Groups together GetRecords, CreatedRecords, and CurrentRecords into one component, making these easier to set up.
• GetRecords. Pulls in one or more records from the CRM and displays them. You choose a parent module, or a parent record and its child module, then set the criteria and sort order for the records fetched.
• CreatedRecords. Pulls in records created by actions earlier in the kiosk's own flow, which can also be used as decision conditions alongside GetRecords and CurrentRecords.
• Zia Insights. Displays Zia-generated insights for a record, including field prediction, competitor mentions, churn prediction, next best experience, Zia score, recommendation, similarity recommender, and best time to contact.

Fields

Fields collect data from users or display previously collected or CRM data. These are separate from CRM fields, which gives you more flexibility over what you collect and how it's presented. Availability of each attribute by field type:

Buttons

Every screen can have buttons, each with its own label and style, displayed right to left, and each creating its own branch in the flow.

Kiosk Field, Screen Field, and Action Fields

Kiosk Field groups together fields added on screens with fields generated by actions. Screen Field lets you display data collected on a previous screen, useful for showing it back to the user for reference. Action Fields let you display data collected from actions that have already run in the kiosk.

Decision

A decision component branches the kiosk's flow automatically based on existing CRM data or data from earlier screen fields, acting as the automatic counterpart to a screen's buttons. You define criteria for each branch, and there is always a default path used when none of the other criteria are met.

Action

Actions connect the data gathered in screens with the rest of the CRM, and run automatically whenever the user's path through the kiosk leads to them. Data gathered in earlier screens can be used as input, for example as a function's arguments. Available action types are Field Update, Assign Owner, Tag (adding or removing), Email Notifications, Add Note, Activities (Add Task, Schedule a Call, Add Meeting), Create Records (Predefined Configuration or Via User Input), Convert, Webhooks, Functions, Open Record, and Open Link.

Create Records

Predefined Configuration creates records automatically during a kiosk's execution, using static values or data from earlier screens, and suits predictable, recurring tasks. Via User Input instead lets records be created live, using a Quick Create pop-up, avoiding the need to replicate, map, and merge fields in advance, which suits scenarios where the exact information needed only becomes available while the kiosk is actually running, such as a sales rep capturing a product demo request mid-call, or a support agent logging updated contact details during a live call.

To use Via User Input: select Create Record, then Via User Input, when setting up the kiosk. Enter an Action Name and choose the Module and Layout. During execution, the Quick Create layout for that module appears, and you can pre-fill frequently used values in advance, with users entering the rest live.

Sequential actions

Turning on Wait for Completion for an action means the next action only runs once the current one finishes, rather than running in parallel by default. This lets the kiosk wait for an action to complete before showing the next screen, so that action's response can be used if needed.

With Wait for Completion enabled, you can optionally add a Failure Path, giving the flow both a Success path and a Failure path with their own next steps, in case the action fails during execution. For Webhooks and Functions specifically, you can also show a customised message, such as a title of "Processing actions..." and a description of "The next screen will appear once the current actions are completed," while the kiosk waits for a real-time response.

Using a function's or webhook's response

To reuse a function's response in later steps, it must return a JSONObject. Deluge functions only return Void or a String, so build the object and convert it with toString(). Java or Node.js functions must return the JSONObject via a single basicIO.write() call, additional calls give unpredictable results. Webhooks must return a valid JSONObject; plain text, numbers, and arrays are not accepted. A JSONArray is never supported, whether as the response itself or nested inside it, so to return multiple values or record IDs, give each one its own key within a single JSONObject, for example:

A function that returns a mappable String must be built in the new Function Console. A function built in the older editor can still be used as a sequential action, so the kiosk waits for it, but it cannot return a String, so its output can't be mapped to fields.

Mapping a function's arguments and response

To map a function's arguments: open the function and click Add Arguments to open Argument Mapping. For each argument, enter its name, click the value field, and type # to open the Add Merge Field picker. Select the kiosk, the data source (CurrentRecord, a GetRecords result, a Zia Agent, or a previous screen), and the field, and repeat for each argument before saving. You can also save the association without values and add them later through the kiosk before test execution.

Argument Mapping (using #) defines where a value comes from at run time and resolves dynamically. This is separate from Input Parameters, a one-time set of test values (no # picker) used only to execute the action once during setup, so the kiosk can read the shape of its response. To generate the response fields, click Execute on the function or webhook action with Wait for Completion turned on, enter a real test value for each argument in the Input Parameters dialog, for example a genuine record ID, and continue. The kiosk runs the action for real and opens Map Response, where each returned value appears as a result.<key> path that you map to a CRM field type and label. These mapped fields are then available in Action Fields on a screen, in decision criteria, and in later actions.

Configuring a webhook

A webhook is set up through the webhook builder rather than Argument Mapping. Clicking Configure Webhook lets you set the HTTP Method (such as POST), the URL to Notify, the Authorization Type (General or Connection), Header, Module Parameters and Custom Parameters, and the request Body and its type. Its response is captured and mapped the same way as a function's, and because webhooks run in real time, the kiosk asks for confirmation before executing, given the risk of data duplication.

Execution limits and failures

A function or webhook used as a sequential action has a maximum execution time of 10 seconds. If it exceeds this, or fails for any reason including socket, thread, or connection timeouts, the action is marked as failed. If a Failure Path is configured, the flow follows it instead, the failed action's response becomes unavailable to later steps, and any records it would have created are not carried forward.

Worked example: logging a renewal assessment

A kiosk collects renewal details across a few screens, then calls a function to log the assessment. In Argument Mapping, an argument is added for each value the function needs, record-based values such as Lead ID mapped to CurrentRecord fields, and user-entered values mapped to the relevant screen fields, using # for each. The function builds its response as a JSONObject and returns it as a string, for example {"status":"logged","assessmentId":"..."}. Wait for Completion is turned on with a Failure Path added, so if the function errors or exceeds 10 seconds, the flow routes to a screen asking the user to retry. To capture the response as usable fields, the action is run once with real test values in Input Parameters, and the resulting result.status and result.assessmentId values are mapped to CRM field types and labels in Map Response. At run time, on success, these fields populate and can be shown via an Action Field on the next screen, and a Decision component can separately route the flow based on the actual value of result.status, distinct from the Failure Path, which only handles the function failing to run at all.

Loops

Loops let a kiosk repeat a set of steps automatically, without you having to recreate the same screens or actions multiple times. Admins define a process once and run it repeatedly based on conditions, which simplifies processing multiple records in one flow and reduces duplicate configuration.

With loops, you can process multiple records in a single flow, repeat actions like approvals, updates, or data capture, build kiosks that adapt to user input, avoid duplicate configuration, and handle bulk operations more efficiently, resulting in simpler, faster, and easier-to-maintain kiosks.

Loops are configured by creating a loop connection between two kiosk elements, such as screens, actions, or decision components. Without loops, admins would need to manually recreate screens or actions for every repeated process, or for every record fetched via a GetRecords action.

Controlling how a loop runs

The maximum number of iterations can be set three ways: based on GetRecords, running once per record fetched; as a static value between 2 and 100; or based on a field value carried over from earlier steps. Users can also be allowed to end a loop manually via an End Manually button on a screen, which is only available when screens are used within the loop.

Use case: scheduling calls across multiple leads

A sales manager fetches a list of leads with GetRecords, and each needs a follow-up call scheduled. With a loop, the configured action runs automatically for every lead, without the manager needing to re-trigger the flow each time, handling the whole batch in one continuous run.

Nested loops

Kiosk Studio supports nesting one loop inside another, up to two levels deep. Even with nesting, the total number of executions across all levels combined is capped at 100.

For example, processing customer orders and their items: the outer loop retrieves each order one by one, and for each order, an inner loop runs through every item, updating details and marking each as processed. Once every item in an order is done, the inner loop ends and the outer loop moves to the next order, continuing until every order has been processed.

Data in kiosks

Beyond gathering input through screens, kiosks draw on several sources of existing data.

CurrentRecords

When a kiosk is opened from a record detail view or a module's list view (for a specific record), it can use that record's data as CurrentRecords. If a kiosk is opened from somewhere that isn't tied to a specific record, CurrentRecords will be null.

GetRecords

GetRecords fetches one or more records from a CRM module, and can be used in screens, decisions, and actions. A single-record output shows one record, with its fields usable in later screens, decision criteria, and actions. A multi-record output can allow either single selection, where multiple records are shown but only one can be chosen, or multiple selection, where several records can be picked for use in decision criteria or in email templates via Table > GetRecords.

You can now choose to fetch all records from a module into a GetRecords screen rather than a limited subset, which suits scenarios where users need to see or act on a complete set of records. Pagination has been added to GetRecords screens to make navigating large data sets easier, and the selection limit has increased from 10 to 100 records. Every kiosk also auto-loads the first GetRecords screen without needing a manual refresh, whether the kiosk is opened from the home page, Canvas, record detail view, a Blueprint, or a custom button.

CreatedRecords

Turning on Wait for Completion on a create record action means the records it creates become available in the next screens as CreatedRecords. These can now also be used as conditions in Decision components, grouped under KioskRecords alongside GetRecords and CurrentRecords, and can be referenced in Action components too, for example configuring an Update Field action to target CreatedRecords rather than an existing record.

Merge fields

A merge field is a reference to another field that gets replaced with that field's actual value when the kiosk is accessed. A merge field can point to GetRecords fields, a previous screen's field, the current record's fields, a CreatedRecord's fields, a User module field (for the person accessing the kiosk), or Organization fields. They can be used within screens, by enabling Merge from Module and pressing # to pick a field, useful for customising instructions or displaying CRM data for reference, and within email templates, to personalise notifications.

Queries

Queries let a kiosk capture and store data directly in Zoho CRM using an API or COQL, including data from third-party services. They can be added to a Screen, to retrieve data entered on previous screens, or to a Decision's criteria, though only if that data was already retrieved on a previous screen in the same kiosk.

Adding a query to a screen

1. Click the plus icon to add an element, select Screen, and click Add.
2. Select Get Data via Queries, then click New Query.
3. Select an existing query from the list, or click Add Query to build a new one.
4. Choose a source: CRM-Module, CRM-COQL, or your own custom source.
5. Enter the query name (the API name fills in automatically), select the module and any related module, and choose the fields.
6. Enter the criteria that determine which records are retrieved.
7. If needed, use the Serializer to reshape the response with JavaScript before saving.
8. Optionally add advanced conditions, then click Next, edit the query name, and choose which fields to retrieve.
9. Choose whether to retrieve a single record (pick the fields to display and save) or multiple records.
10. For multiple records, choose an Identifier, a unique field used to tell fetched records apart, such as a Lead ID, then set a selection limit, choose the fields to display, and save.

Adding a query to a decision component

1. Click the plus icon to add an element, select Decision, and click Add Conditions Based On.
2. Select Queries from the drop-down.
3. Select a query, select the criteria, and click Done.

Query field limits

Overall, a maximum of 100 fields can be displayed across a query's results. For example, if you already use the maximum 40 Number fields, plus 60 across Decimal, Percentage, and Currency fields, no further fields of any type can be added to that query.