Navigation
17.1. Service Requests: Self-Service Forms for Tickets and Stored Intake
Publish structured self-service forms in AlgaPSA to create routed tickets or retain completed questionnaires as immutable submissions without tickets or workflows.
Service Requests let you publish a catalog of structured, self-service forms to your client portal. When a client picks a request from the catalog and fills it out, AlgaPSA records the submission and uses the definition's completion mode. A ticket-based request creates properly routed work; a store-only request keeps the completed response without creating a ticket or workflow.
How Service Requests Differ From Tickets:
A ticket is free-form: the client (or technician) writes whatever they need. A service request is a guided form for common, repeatable asks, where you control exactly which questions are asked and where the resulting work lands. Use them for predictable requests such as:
- New user onboarding and offboarding
- Access and permission requests
- Software installation
- Hardware or equipment requests
- Any standard intake you'd rather not handle as a blank ticket
Keep Questionnaires as Stored Submissions:
Use Store Only for information you need to retain without putting work in the service desk queue. For example, GreenLeaf Dental Group can complete an onboarding questionnaire about office hours, site contacts, and maintenance windows. The completed answers and attachments remain in request history as an immutable submission, with the requester, client/contact, submission time, and form version.
| Completion choice | Expected result |
|---|---|
| Ticket-based request | Stores the response and creates a ticket using the configured routing. |
| Store Only | Stores the response and completes successfully with no ticket, workflow execution, or ticket notification. |
Choose Store Only in the form editor under Execution > Execution Provider, then publish the definition. Existing ticket-based requests keep their current behavior. Draft changes do not change the live published mode or rewrite earlier submissions.
Review the response from the definition's Submissions section in the MSP app; clients can find it under My Requests in the portal. For a store-only request, a successful submission with no ticket link is the intended result. See 17.3. Build the Request Form with Fields, Help Text, and Options and 17.6. Review Service Request Submissions and Linked Tickets for setup and review steps.
The Lifecycle of a Service Request:
Each service request moves through three states:
- Draft — a work-in-progress that clients can't see yet.
- Published — live and available in the client portal.
- Archived — retired and hidden from the catalog (can be restored later).
A published request that has unsaved edits shows as Draft Changes, meaning the live version differs from the draft you're editing.
Where to Find Service Requests:
- As an MSP user, open Service Requests from the sidebar to build, publish, and monitor your catalog.
- As a client, the published catalog appears in the client portal, where end users browse services, submit requests, and track their status under My Requests.
How the Pieces Fit Together:
Building a service request follows a simple path, each step covered in its own article:
- 17.2. Create a Service Request and Set the Basics: start a draft and fill in the basics.
- 17.3. Build the Request Form with Fields, Help Text, and Options: add questions and choose store-only completion when no work needs routing.
- 17.4. Configure Ticket Routing and Execution for Service Requests: configure routing for requests that create work.
- 17.5. Publish, Version, and Manage Service Requests: go live and maintain the catalog.
- 17.6. Review Service Request Submissions and Linked Tickets: track tickets and stored responses.
- 17.7. How Clients Submit Service Requests from the Portal: the client portal experience.