Start with the decision each answer should support
An intake form should help somebody take the next useful action. For an illustrative SaaS demo request, the team may need to know whether a visitor wants an individual account, a team demonstration, or help migrating. A single long questionnaire makes all three people answer questions that may not apply.
Write the receiving team's decision beside each proposed question. If a field does not affect the response, routing, or preparation, remove it from the first version. Keep the reason for asking visible to respondents when the answer requires effort, such as describing a migration or uploading supporting material.
Map three paths before opening the form builder
Tally's conditional logic supports actions such as showing or hiding blocks, skipping pages, and choosing a thank-you page. Conditions can match all or any criteria. Its documentation currently lists conditional logic as available without upgrading, though other features may have separate plan requirements.
For this example, start with a question about the visitor's goal. Keep contact details shared, then show a small branch for each goal. Use the following map as a proposed design, not a claim that these questions will increase completion or qualification for every business.
| Selected goal | Relevant follow-up | Useful next step |
|---|---|---|
| Try it individually | What task are you trying to finish? | Provide the relevant getting-started resource |
| Arrange a team demo | Who will attend and what should the demo cover? | Prepare an appropriate demonstration |
| Discuss a migration | Which system and data need to move? | Review requirements before promising a migration |
Build and test the conditional blocks
Add the shared questions, create the branch-specific blocks, and hide blocks that should appear only when their conditions match. In Tally, /logic adds a logic block. Configure each branch deliberately, including which answers are required while that branch is active. Page jumps take effect when the respondent proceeds with Next or Submit.
Do a full pass through every branch, then change the first answer after entering a later response. Check whether irrelevant information survives in the submitted record and whether a hidden required question prevents completion. These are important checks because the form can look correct on its initial path while behaving unexpectedly after an answer changes.
- Each choice reveals only the questions that belong to it.
- Changing the choice produces the intended new path.
- Required questions do not trap a respondent on an irrelevant branch.
- The confirmation explains what will happen after submission.
Use hidden fields for context, with clear limits
Tally hidden fields receive values from URL parameters. They can capture a campaign label, a referring page, or another piece of context supplied with the form link. They differ from a normal question whose visibility is hidden by conditional logic.
A campaign value such as spring-demo can help the team identify which invitation led to a response. Treat it as supplied context: people can edit a URL. Never use a hidden field alone to decide that somebody has a paid subscription, belongs to a customer account, or may access private data. Avoid putting confidential information in form URLs.
Make the submission handoff observable
Tally webhooks send new submissions to an endpoint as JSON. The documentation covers a signing secret, delivery logs, and retries when delivery does not succeed. If you use a custom endpoint, verify its signature and make repeated delivery safe to handle.
For the demo-request example, retain the submission identifier when creating the follow-up task. If the receiving service times out and Tally retries, the same form response should not become several sales tasks. Keep an identifiable connection between the submitted response and the downstream record so somebody can investigate a missing handoff.
Evaluate the form by the quality of the next action
Review whether someone can complete the form on a phone, understand its labels, correct a mistaken answer, and recognize the confirmation. Separately check whether the receiving team gets enough information to respond. A shorter form is helpful only when it still supports the intended task.
Tally is worth evaluating when a hosted form and branching logic cover the collection step. If your process requires sensitive account decisions or complex permissions, put those decisions in an appropriately authorized application. Let the form collect a request and let the receiving system decide what that request is allowed to do.
Sources and editorial method
Official documentation linked in this guide was checked on October 26, 2026. Product behavior, pricing, and plan limits can change. The workflow examples are editorial proposals, not reports of a hands-on benchmark or customer results. Confirm the current documentation before implementing the workflow.