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.
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.
A form with the Create Request / Violation action turned on. This is what actually files the request.
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.
Click Forms & Polls in the main navigation menu and create a form, or open an existing one.
Add the questions you want answered. File Upload questions are especially useful here, since the files are copied to the request.
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.
Click Save Configuration. The card's badge changes to Enabled.
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.
Click Publish & Set Live, then Publish.
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.
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:
Go to Requests and open the request type, for example Architectural.
Click the gear icon (Review settings).
Turn on How applications arrive.
Under Application form, choose your form. It must be published and must file this type of request, or the settings won't save.
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.
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.
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.
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.
They answer your questions, starting with the impact area or project type if you chose Ask in Form.
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.
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").
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.
