Feature Requests

Limit the ability to remove assignees from requests to Admins and Managers only. Currently, responders are able to remove accounts from the “Assign To” section of a request. This can lead to unintended unassignment, loss of accountability, or disruption of workflow ownership. [SAS]

Allow managers to export checklist responses linked to requests as a CSV export (for data analysis and reporting) and as a downloadable checklist file directly from the request. When a request has a linked checklist, managers are unable to extract the checklist form responses in a CSV format. Additionally, there is currently no option to download the linked checklist data directly from the request. [OJJ Foods]

Automatically notify all assigned accounts when a responder adds a new note to a request. Notifications should follow existing notification settings and channels (e.g. in-app, email, messaging integrations). Why This Is Helpful: This ensures all stakeholders stay informed in real time, improves collaboration between technicians and managers, reduces communication gaps, and helps teams respond faster to updates or required actions. [SAS]

Preserve and display the original paragraph breaks and line formatting exactly as entered by the user across web, mobile, and PDFs. Although request descriptions can be entered using multiple paragraphs or line breaks, they are currently displayed as a single continuous paragraph. This reduces readability, especially for longer or more detailed descriptions. [Princeton DG]

Allow users to link a customer to a request. When the request status is updated to Complete, the system should automatically email the completed request PDF to the linked customer, similar to the existing Checklist behavior. [Don Jon]

[Note: This is not about the Service Request Sign off flow, it's the universal custom processing statues] Allow notifications or alerts to be configured per custom processing status, so that when a request is updated to a specific status, the relevant assigned account(s) are automatically notified. This is useful when a request can move between these custom processing statuses. Relying on notes is harder to track Use Case Example: Contractor updates a work order to “Processing (Job Done)” → Manager is notified to review Manager reviews and updates status to “Processing (Revision)” → Contractor is notified to revise Contractor completes revisions and updates status back to “Processing (Job Done)” → Manager is notified again Manager verifies and updates status to “Complete” [Guthrie x PA]

Currently, due dates for requests are typically set by managers or administrators. Responders (e.g. contractors) are unable to define their own timelines for assigned work orders. Proposed Enhancement: Allow responders or contractors to set or update the due date for requests created assigned to or created by them (e.g. as a “Projected Delivery Date”). These due dates should support reminders and notifications, similar to existing due date alerts. Why This Is Helpful: This holds contractors accountable for their own planning and timelines, improves visibility into expected delivery dates, enables more accurate scheduling and follow-ups, and ensures reminders are aligned with contractor-committed deadlines rather than assumed timelines. [CSK Landscape]

To include SOR Table in Custom PDF download. [CSK Landscape]

I would like to request the addition of a “Multiple Dates” field in the system. This will allow users to input more than one date per request, making it easier to track entries that span multiple days

Once a request is submitted, users cannot make edits, even if the request is still in pending or progress. This is challenging for workflows such as incident reports where additional details may need to be added after further investigation. Proposed Enhancement: Allow requests to be editable at any stage before the request reaches the Completed status. Key Requirements: Perhaps requests can only be editable only when the request is NOT in the “Completed” stage. Role-based editing permissions restricted to: Admins Managers Responder Viewers or requestors (from messaging channels) should not have editing access unless explicitly allowed. Optional: Maintain an audit log of edits for transparency. Use Case Example: Engineers handling incident reports can add new findings after initial submission. They can refine information as they review ongoing requests. Benefits: Supports evolving information during investigations. Reduces need for duplicated submissions. Ensures accuracy and completeness of request data before finalization. [Princeton DG] [SAS]