Where to manage Request Types
From the Dashboard:
Open Requests from the feature board
Select Request Types from the drop-down
This screen lists all existing Request Types across your selected sites.
From here, you can:
Create a new Request Type
Edit an existing Request Type
Delete a Request Type
1. Creating a new Request Type
Creating a Request Type is a structured, multi-step process. Do not rush this. Once published, the Request Type becomes live immediately.
Step 1: Start a new Request Type
Select the plus (+) icon in the top-right corner
A new Request Type setup screen opens
You will see three tabs:
General
Custom Fields
Settings
The Request Type is not live until you save it.
Step 2: Complete the General tab
This tab defines the core identity of the Request Type.
Request Type name
Mandatory
Must be unique
Use plain, resident-friendly language
Example: Maintenance
Sites
At least one site must be selected
Multiple sites can be selected
Removing all sites is not allowed
Subtypes
Optional
Up to eight (8) subtypes
Used to refine classification without creating new Request Types
Subtypes should remain simple and descriptive.
Step 3: Configure Fields (mandatory and custom)
All Requests include three mandatory inputs by default:
Request title or subject
Request description
Optional image upload
These cannot be removed.
You can then add custom fields to collect additional information.
Custom field types available
Text
Yes or No
Number
Date
Mandatory behaviour
Text, Number, and Date fields can be marked as mandatory
Yes or No fields cannot be enforced as mandatory
If unanswered, they default to “No”
Use mandatory fields carefully. Overuse slows down submissions and reduces adoption.
Custom fields added after a Request Type is live:
Apply only to future requests
Do not retroactively apply to existing requests
Step 4: Configure Settings
The Settings tab controls notifications and operational behaviour.
Admin notifications
Enable to notify a specific admin when this Request Type is submitted
Additional notification emails can be added
Emails can be internal or external
Service date
Can be required or optional
Best practice is to keep this optional unless operationally critical
Service provider assignment
Enables assigning subcontractors or third-party providers
Strongly recommended where external work is involved
Once these settings are saved, they apply immediately to all new requests of this type.
Step 5: Publish the Request Type
When you save the Request Type:
It becomes live immediately
Staff can create requests from the Dashboard
Residents can see and use it in the app (if resident-visible)
There is no draft or staging mode. Always double-check before saving.
2. Editing an existing Request Type
Editing is done from the Request Types list.
How to edit
Locate the Request Type card
Select the three vertical dots
Choose Edit
You can now update the Request Type.
What you can safely edit
Request Type name
Assigned sites (must always keep at least one)
Subtype names
Notification settings
Admin and email recipients
Changes to these take effect immediately.
Subtype deletion warnings
Subtypes can be deleted
If a subtype is already used on live requests:
Deletion is irreversible
The subtype will be removed from those requests
You will receive a warning before confirming.
Custom fields on live Request Types
New custom fields apply only to future requests
Existing requests remain unchanged
This prevents data inconsistencies but means planning matters.
Service provider assignment changes
Be cautious when editing this setting.
Turning it off does not remove existing service providers
It prevents assigning providers to new or unassigned requests
Editing this mid-workflow may confuse staff
Best practice: do not change this once active work exists.
3. Deleting a Request Type
Deletion is intentionally restricted.
How to delete
Open the Request Type card
Select the three vertical dots
Choose Delete
When deletion is blocked
You cannot delete a Request Type if:
There are live requests using it
There are subtypes in use on active requests
To proceed, you must:
Reassign or complete all associated requests
Or move requests to another Request Type
Deletion should be treated as a cleanup task, not a routine action.
Operational guidance
Follow these rules to avoid problems:
Design Request Types broadly
Use subtypes instead of new Request Types
Avoid editing core behaviour mid-workflow
Test changes before enabling for residents
Contact support if unsure
Once Requests are live, small configuration decisions have wide operational impact.