# Form structure
All forms should start on an SF.gov transaction page with a CTA button that leads to the form. ([More information about transaction pages on SF.gov](https://sfdigitalservices.gitbook.io/style-guide/templates/transaction-page))
The form contains:
* An introduction
* Form pages with fields
* A confirmation page
### Form introduction
Every form needs a short introduction that sets expectations and explains:
* What the form is for
* What the form will ask you about
* What to expect after you fill out the form
This should be friendly, explain to them why they want to fill it out, and about how long it will take to complete.
### Sections
If a form has more than 9 questions, break the form into sections.
Name each section and include the name in the page titles.
### Page names
Page names must describe the group of inputs on the page.
They must not be the field label.
### Forms for repeat customers
Rely on user testing to deviate from these recommendations.
For example, for building permitting, we saw that repeat customers, like architects, expected more questions on one page. On building permitting forms, we group more inputs together as parts of the project, instead of following one question per page.
Ideally a page has fewer than 7 inputs.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://sfdigitalservices.gitbook.io/style-guide/how-to-write-forms/form-structure.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
