Design your Zoho CRM kiosk around an outcome: find the right person, identify the owner and leave a clear next action. Start with the duplicate check. A polished intake screen is little help if every submission creates another copy of an existing prospect.
Use the example below as a proposed intake design. Map it to your actual modules and fields before building. The pass condition is an appropriate record and a follow-up linked to it, including when the person already exists.
Choose Kiosk Studio, Blueprint or a Wizard
Kiosk Studio builds guided CRM capabilities without code. Screens can collect input, record retrieval can find matches, and decisions can choose a route from the information available.
Choose the tool by the job you need to design:
| Your main requirement | Route to evaluate |
|---|---|
| Guide intake through a lookup and several CRM actions | Kiosk Studio |
| Enforce an agreed progression through process stages | Evaluate Blueprint against your stage rules |
| Break a long entry form into a guided sequence | Evaluate a Wizard against your entry requirements |
Confirm the alternatives in Zoho's help docs before committing to a feature-specific design. If the task is mainly visual arrangement, read the Canvas layout guide. Keep intake logic separate from decisions about where fields appear.
Define the intake fields and expected outcomes
Write down the input contract before arranging screens. For this example, collect the person's name, email, company, request and proposed owner. Check your actual layout for required fields; do not assume a sample form includes everything your organization requires.
Define the matching policy too. An email match should open a review route. A missing email should require another agreed identification step. Several matches should pause for review rather than select the first result.
Use these expected outcomes:
- No existing person: prepare a new lead with the approved field values.
- One clear match: use the existing record without replacing populated details by default.
- Ambiguous match: show candidates and stop automatic creation.
- Successful intake: add the agreed follow-up against the chosen record.
Include existing contacts in your duplicate-review plan. The leads already present as contacts check helps define that exception before you create another lead.
Build screens, GetRecords and decision branches
Start with an identification screen. Give each input a useful label and explain why you need it. Store the submitted email as the value the retrieval criteria will use.
Zoho's kiosk overview describes GetRecords as a retrieval component configured with a module and criteria. It supplies information; it is not the create-record action. Configure the intended module and compare its email field with the screen input.
Add a decision after retrieval. Route no results to a new-record review screen. Route a clear result to an existing-record summary. Keep a separate exception for multiple results, and test how your chosen components represent an empty result.
On the new-record route, map each input explicitly: screen name to the intended name field, email to email, company to the agreed destination, and owner selection to the intended owner value. Show a review summary before proceeding. On the match route, show enough identity information for a person to confirm the result without exposing unnecessary details.
Connect actions and place the kiosk
Kiosk actions include creating records, adding tasks and executing functions. Sequence your design so the follow-up uses the selected existing record or the result of successful creation. Do not prepare a task against an assumed identifier before its parent exists.
Write the task subject, owner and due-date rule in plain language before mapping them. Decide what the user should see if record creation succeeds but a later action fails. Your recovery plan should reuse the created record rather than repeat the entire intake blindly.
The guide lists home, list, record detail and Canvas pages as kiosk placements. Choose the entry point that matches where intake happens. A record-page launch needs a different context check from a home-page launch.
If you need portal access, check Zoho's help docs for the intended surface before promising that placement. For custom interactive interface requirements, compare the widget guide before adding complexity to the kiosk.
Ask the AI Assistant to build and test the flow
The Zoho CRM AI Assistant can build the intake configuration and supporting CRM fields, layouts, functions and tasks from your instructions. Give it the matching policy, owner rules and expected outcomes rather than only a screen title.
Build lead intake that searches the submitted email before creating a lead. Show existing lead and contact matches for review, use our territory owner table, and add the approved follow-up to the chosen record. Show the field mappings and action sequence before applying changes, then test the no-match and ambiguous-match routes.
It applies the Kiosk configuration and test-record changes after you approve the flow. Review the proposed configuration, then inspect the resulting record and task after execution. Ask for actual identifiers and outcomes for each test, including any incomplete action. The assistant works inside Zoho CRM; it does not configure an external intake website or another product.
Troubleshoot file uploads, record retrieval and edit access
Can a kiosk upload files? Verify the current screen components and the intended upload destination in Zoho's help docs. The documented facts here do not establish upload support for every screen. Keep a file requirement unresolved until you have tested it in the intended placement.
If GetRecords finds nothing, inspect the selected module, criteria and the actual input value. Check the email spelling and the test user's record access. Then check that downstream actions read the retrieval result you intended.
If you can no longer edit the kiosk, record the affected user, kiosk and exact error. Compare the current profile and configuration access with the last working setup. Do not recreate the flow merely because its edit screen is unavailable; you could leave users with two competing versions.
Test and maintain the kiosk
Test a new person, an existing lead, an existing contact, a blank identifier and several possible matches. Repeat the tests under the intended user's access. Confirm the owner, record link and follow-up after every successful route.
Also test reopening intake after a partial failure. Your recovery notes should identify which action completed and which still needs attention. Avoid using a repeated submission as an undocumented retry mechanism.
Keep a named maintainer and an example record for each route. Retest after a field, owner rule or placement changes. The fetched Kiosk Studio guide lists loop actions as work in progress; check the current guide before making repeated processing depend on loops. A small flow with verified branches is a useful starting point for later changes.