Use case: You want one place to see every switch that changes how requests work in your portal: what they're called, which statuses mean "done", what clients can see, and which extra tabs requests get.
The Requests module settings control how requests behave for everyone in your portal. This article walks through each setting in the order you see it on the page, with a link to the detailed article where one exists.
Before you start
Only portal admins and admins can open and change these settings.
Changes apply to the whole portal, for all clients and team members.
Open the Requests settings
In the sidebar, go to Settings > Modules and extensions.
On the Modules tab, click Requests.
The page opens on the General tab. Change what you need, then click Save changes at the bottom of the page.
The Automations tab next to General sets the Default status after client comments and Default status after team or admin comments. See How to automatically change statuses.
Names and statuses
What to call a request (singular) and What to call requests (plural): rename "request" across the portal, for example to "Task" and "Tasks" or "Project" and "Projects". The new name shows in the sidebar, page titles, buttons and messages.
Status after creation: the status every new request gets when it is submitted.
Completed status: the status ManyRequests treats as "done". Marking a request as complete moves it to this status.
Closed status: the status for requests that ended without being delivered. Together with the completed status, it decides which requests count as finished. See What is the difference between "Closed" vs "Completed" status.
To add or rename the statuses themselves, see How to create custom project statuses.
Comments, queue and views
Disable comments on completed requests: clients and team members can't post new comments on requests in the completed or closed status. Internal comments and admin comments are still allowed. See How to lock comments on completed requests.
Requests queue: lets clients queue requests beyond their plan's limit of concurrent requests and reorder the queue. Choose which status queued requests get in Queued status. See How to use queue.
Kanban view by default: clients' requests page opens on the Kanban board instead of the list. Clients can still switch views. If the queue is on and the client's plan has a request limit, the queue view opens instead. Team members and admins always start on the list. See How to use Kanban.
Default activity view: what the activity feed on a request shows when it opens, All activity or Comments only. Anyone can switch from the filter on the request. See the article "How to filter the request activity feed".
Allow clients to create requests as cards: clients can add a request from the Kanban board with just a title. When it's off, they must use the full request form.
Request numbers: gives each request a reference number. Set the first number in Starting number. See How to add request numbers.
Checklists, reviews and time
Request checklists: adds a Checklists tab to requests. With Full checklist access for clients on, clients can view and manage checklists like team members. With it off, they only see checklists assigned to them and can't edit them. See How to create templates and checklists on requests.
Request reviews: clients can leave a review when a request is completed. See Client reviews on completed requests.
Request time tracking: adds a Timesheets tab to requests. It turns on by itself when you create or save a time-based service. See How to use time tracking.
Client access to time tracking: clients can see the Timesheets tab on their requests and the time reports.
Time rounding: rounds logged time for reports and invoices. Pick a Rounding method (Round to nearest or Round up) and a Time segment (15 minutes, 30 minutes or 1 hour). See How to set up time rounding.
Require approval for team time: time logged by team members stays pending and doesn't count until an admin approves it. Time logged by portal admins and admins doesn't need approval. See the article "How to require approval for team time entries".
Credits, workload and the request form
Request credits: you can set a credit cost on a request, which is deducted from the client's balance. It turns on by itself when you create or save a credit-based service. See How to create credit based services.
Workload view: adds a workload view that shows time allocation per team member, and two fields on each request: Time estimate and Start date. With Time estimate client access on, clients see the time estimate too. See How to use the workload management feature.
Show request details on the create form: when it's off, the title, description and image fields are hidden on the create form, so clients only fill in your service's form fields.
Include time in due dates: due dates get a time of day, not just a date.
Request custom dropdown: adds one dropdown field of your own to request details, with a matching column in the request list. Name it in Dropdown label. See How to use custom dropdown.
Client custom columns: choose which columns clients see in their requests list with Configure client columns. When it's off, clients see the default columns. See How to create custom client columns.
Create requests via email: clients can create requests by emailing the Inbound email address shown under the switch. See How to send requests via email.
Canned responses: the link at the bottom of the page opens your saved replies. See How to create canned responses.
Tips
Nothing changes until you save. The button at the bottom shows Saved when there are no unsaved changes, and Save changes when there are.
Saving resets the default view. After you save, each client's requests page opens in the default view again the next time they visit, even if they had switched views before.
Who can do what (for example whether team members see all requests or clients can change a status) is set in the Users module, not here. Only the portal admin can open it. See Specific permissions for admin, client, and team.