--- title: "Collecting Requests Through a Form" description: "Build a form that files a request or violation when it's submitted, ask your own questions up front, and make it the way residents submit that type of request." url: https://support.communitrak.com/en/articles/42-collecting-requests-through-a-form collection: "Requests & Violations for Leaders" updated: 2026-10-13 language: en --- # Collecting Requests Through a Form Build a form that files a request or violation when it's submitted, ask your own questions up front, and make it the way residents submit that type of request. The standard **New Request** form asks for a title, an impact area, and a description. If your community needs more than that, for example the make and model of a broken appliance or the dimensions, materials, and drawings for a proposed fence, you can collect requests through a form instead. Members answer your questions, and Communitrak turns each submission into a request automatically. ## **Who can do this** - Building the form and setting up its request action requires the **Create, Update, & Edit Forms** permission. Publishing it requires **Open & Close Form**. - Setting the form as a request type's application form requires the **Manage Request Review** permission. - Turning on the Forms & Polls banner requires the **Update Community Preferences** permission. Some options may be unavailable or appear differently depending on your level of account access. ## **How it works** 1. A **form** with the **Create Request / Violation** action turned on. This is what actually files the request. 2. Optionally, the form is set as the **application form** for a request type. Members who click **New Request** for that type are either sent to your form or shown a link to it. For building forms in general, see **Creating and Managing Forms and Polls**. ## **Step 1: Build the form** 1. Click **Forms & Polls** in the main navigation menu and create a form, or open an existing one. 2. Add the questions you want answered. File Upload questions are especially useful here, since the files are copied to the request. 3. Open the **Actions** tab, find the **Create Request / Violation** card, and click **Configure**. Fill out the **Configure Request/Violation** dialog: - **Request Type** (required): General, Maintenance, Architectural, or Violation. - **Request Title** (required): the title each request gets, for example "Architectural review request." - **Title each request from an answer**: pick a question, such as a short description of the work, and each request is titled with that answer instead. Short answer, paragraph, dropdown, multiple choice, number, and date questions can be used, and long answers are shortened to fit. This makes requests much easier to tell apart in a list, a search, or an email subject. If the member leaves that question blank, the fixed title is used. - **Impact Area**: where the request is assigned. - **Property (Submitter's property)**: the home of whoever submits the form. The usual choice. - **Amenity**: always one amenity you pick. - **Other**: always a named area you type in. - **Ask in Form**: the form's first question asks the member to choose a household, an amenity (when your community uses Amenities), or another area. For requests (not violations) you can also turn on: - **Let submitters file on behalf of any household**: the household list shows every address in the community instead of only the member's own, so a resident can report a problem at a neighbor's home. Everyone in the chosen household is added to the request's watchlist and notified. - **Show household names alongside addresses**: appears once the option above is on. The list reads "Smith Household, 123 Main St" instead of only the address. Leave this off if you'd rather not show members who lives where. - **Project Type**: what kind of work the request is about, such as a fence or a roof. Choose one, **Ask in Form** to let the member pick, or **Don't set one**. This only appears when the request type has a list set up in its review settings, under **Project types** for architectural requests or **Categories** for general and maintenance. It drives the list filters, so leaving it unset means requests from this form can't be filtered by kind of work. Not available for violations. - **Request Header Text**: context that appears at the top of the request, above the questions and answers. - **Default Deadline**: sets the request's deadline to this many days after it's submitted. Leave it blank for no deadline. 4. Click **Save Configuration**. The card's badge changes to **Enabled**. 5. Optionally click **Manage Watchlist** to add members or groups who should be notified each time this form files a request, for example your architectural committee. 6. Click **Publish & Set Live**, then **Publish**. > **Info:** **Note:** Anonymous forms can't file requests, since a request is always tied to the person who submitted it. A form with this action can't be made anonymous, and the action can't be added to a form that already is. ### **Required documents and fees** If the request type has a list of required documents (set under **An application must include** in the type's review settings), each question in the form can be linked to one once the action is configured. Edit the question and choose the document under **Satisfies a required document**. When a member answers that question, the document is checked off on the request automatically. This happens on request types that use committee review. On a single-reviewer type, a leader ticks the checklist on the request. To charge an application fee, add a **Payment** question to the form. The payment is linked to the request it files. Amounts on the form are set on the form only. If your community also lists application fees in its request settings, the editor shows them as a reminder, and you'll need to keep the two in step yourself. ## **Step 2: Point members to the form (optional)** You can set the form as the **application form** for one type of request, and choose whether members must use it or are simply pointed to it: 1. Go to **Requests** and open the request type, for example Architectural. 2. Click the gear icon (**Review settings**). 3. Turn on **How applications arrive**. 4. Under **Application form**, choose your form. It must be published and must file this type of request, or the settings won't save. 5. Under **Should residents have to use it?**, choose one: - **Require it** (the New Request button goes to the form): members who click **New Request** for that type go straight to your form, and can't file that type any other way. - **Suggest it** (they can still use the standard form): **New Request** still opens the standard form, with a note at the top linking to your application form. Members can use either. 6. Click **Save settings**. The setting is per type, so you can require a form for architectural requests, suggest one for maintenance, and leave general requests alone. When a form is required, leaders with the **Manage Request Review** permission get a small menu beside **New Request** with **File for myself** and **File for a member**. **File for myself** goes to the form like anyone else. **File for a member** opens the standard form, so the office can still enter an application that arrived by phone or on paper. ## **The Forms & Polls banner** There's also a simpler, community-wide signpost. In **Community** > **Preferences**, under the Requests preferences, check **Forms & Polls Banner**. Members then see a blue banner on the Requests page reading "To submit a new request, please complete a form in the Forms & Polls module," with a **Forms** button. - The banner is a suggestion, not a requirement. The **New Request** button still works. - It links to the Forms & Polls list, not a specific form, so give your form a clear name. - It appears on every request type's page, except a type that has a required form. For most communities, setting an application form for the type (Step 2) works better: the **New Request** button stays where people expect it and leads to the right form, whether you require it or suggest it. ## **What the member sees** 1. The member clicks **New Request**. With **Require it**, they land on your form. With **Suggest it**, they see the standard form with a note linking to yours. They can also open your form from Forms & Polls. 2. They answer your questions, starting with the impact area or project type if you chose **Ask in Form**. 3. When they submit, the confirmation says "Your request has been filed," and **View my request** takes them straight to it. From there they can follow it, comment, and add files like any other request. ## **What gets created** Each submission files a pending request with: - The title from your configuration, or the member's answer if you chose **Title each request from an answer**. - A description with your header text, followed by each answered question and its answer. Uploaded files show as "\[File attached\]" and signatures as "\[Signature provided\]". - The submitting member as the creator and on the watchlist, plus the members of the household the request is about. That is the member's own household when the impact area is their property. - Everyone you added under **Manage Watchlist**, including the members of any group you added, as of the moment the form was submitted. - Any files uploaded in the form, copied to the request's **Attached Files**. - The project type, if one was set or chosen. - A deadline, if you set a default. - Any payment made through the form, linked to the request. - An activity entry reading "Created from form submission" followed by the form's title, so you can always tell where a request came from. - If the request type uses committee review, the review opens straight away and the committee is notified ("Sent to committee review from form"). ## **Things to know** - One form files one type of request. For a different form per type, build one form for each and turn the action on for each. - The action can file a violation instead of a request. Use that carefully: a violation notifies the household it targets, and anyone in the form's audience can submit it, whether or not they hold the Create Violation permission. A violation form can't offer filing on behalf of any household or a project type. - On a public form, the only impact area available is **Other**. - If the form already has its own impact-area question, the **Impact Area** setting is hidden. - Clicking **Disable** on the card turns the action off and clears its watchlist. Requests already filed aren't affected. - Members still need the **Create Request** permission to use the **New Request** button. The form itself is available to anyone in its target audience. If you have questions or need help, chat with Communitrak Support from any page using the messenger icon in the bottom-right corner.