> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getvirtualbrain.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Collecting User Inputs

> The three input types, their mandatory routing, and the naming and instruction rules that keep an App's inputs clean

User Inputs are what the person running your App provides at runtime. Every downstream block inherits whatever they contain, so it pays to get them clean.

## Routing is fixed for inputs

Each input type has one mandatory routing behavior.

| Input type          | Routing always          | Why                                                                               |
| ------------------- | ----------------------- | --------------------------------------------------------------------------------- |
| **Free Text**       | Inline `/variable_name` | Short and targeted; the Mainframe needs the full text.                            |
| **Multiple Choice** | Inline `/variable_name` | A single value steering the block's behavior.                                     |
| **Document Upload** | Knowledge Source        | Documents can be long; retrieval finds the relevant parts. Never injected inline. |

<Info>
  A Document Upload always becomes a Knowledge Source, never an inline variable. Injecting a full uploaded document into a prompt is exactly the mistake [Knowledge Sources: Inline vs. Retrieval](/apps-academy/knowledge-sources) exists to prevent.
</Info>

## Rules that keep inputs clean

<Steps>
  <Step title="Aim for 5 to 7 inputs">
    Every extra input adds friction for the end user.
  </Step>

  <Step title="Name inputs deterministically">
    "Job Description" becomes `/job_description`. Lowercase, underscores, no abbreviations, no synonyms. Use the same name everywhere: input definition, prompts, documentation.
  </Step>

  <Step title="Write end-user instructions">
    Fifty words or fewer, for every input. Say what to provide, in what form, with one example. "Paste the full job description, including requirements" beats "Job info".
  </Step>

  <Step title="Use Multiple Choice for anything that branches">
    Analysis depth, target language, report type. Free text has to be interpreted; a fixed set of choices does not.

    <Warning>
      If only one option should be selectable, say so in the input instructions. Single-select cannot be enforced yet.
    </Warning>
  </Step>

  <Step title="Add a Language selector when needed">
    Include a Language selector (Multiple Choice) when the App may serve users in several languages.
  </Step>
</Steps>

<Tip>
  Deterministic naming is what lets a block reliably find its inputs. The same `/job_description` in the input definition, in every prompt, and in your documentation removes an entire class of "why is this block empty?" failures.
</Tip>

See [App Blocks](/features/apps/app-blocks) for how these inputs are wired into each block as it runs.

## Next

<CardGroup cols={1}>
  <Card title="Knowledge Sources: Inline vs. Retrieval" icon="database" href="/apps-academy/knowledge-sources">
    How a block knows what it knows.
  </Card>
</CardGroup>