Service Requests

What is it and what is it for?

Unlike a Service Contract (the commercial agreement that covers a customer over a period) or a Maintenance Order (the technical record of a job already performed on a piece of Equipment), the Service Request is the initial report: the "what happened" and "what's needed" that kicks off the handling process. From a Request you can generate one or more Work Orders (the work each technician actually performs) and keep a full history of status changes through to closing.

Every request has a Status that moves forward according to your company's workflow (for example New, In Process, Closed), a customer-facing Priority and an Internal Priority for your team's own use, and it can be flagged as covered by Warranty or as billable from a source document (typically a Sales Order).

How to use it

1. Pick the view you need. The list (with the In Process, Unassigned and All modes), the Calendar of scheduled requests, or one of the Kanban boards: by Status, by Consultant, by Assigned To or by Transaction Type. They all show the same requests from a different angle.
2. Filter by Customer, Consultant, Assigned To, Subsidiary (if your plan has them), Location, Transaction Type, Tag, Internal Priority, document date range, Project or description to narrow down the list.
3. Click "Create". Fill in the Customer and a Description of the issue or request, both required.
4. Fill in what applies: who's Requesting it (a customer contact), the affected Customer Asset, the Consultant/Technician and the employee it's Assigned To, the Priority and Internal Priority, the Group, the Transaction Type, tags, whether Warranty applies, a related Project, and the source document when the request is billable.
5. Save. AdmCloud numbers the request automatically and validates the information (see "Validations on save" below).
6. Follow up from the detail screen: change the Status, the Priority, the Group or the assigned technician; check the Linked Work Orders, Other Linked Transactions and Linked Service Requests tabs (when your company enables parent-child linking), and the Status Change Summary tab with how many days it spent in each status.
7. Generate a Work Order from the request once a technician is going to perform the work, or check the ones already generated in the corresponding tab.
8. Print the request from its detail, choosing among the available formats.
9. Void the request instead of deleting it once it already has history; it stays visible on the "All" view without losing the record.

Main capabilities

• A list with three modes (In Process, Unassigned, All) plus specialized variants like "List with last contact", to follow up on requests without recent activity.
• Five Kanban boards grouped by different criteria (Status, Status with drag-and-drop and inline editing, Consultant, Assigned To, Transaction Type), plus read-only public versions to share with people who don't have system access.
• A Calendar view for scheduled requests (those with a planned execution date).
• A configurable status workflow, with a summary of how long the request spent in each status.
• Optional linking between related requests (parent-child) when your company enables that feature, plus links to Work Orders and other transactions (Quotes, Maintenance Orders, Location Transfer Requests, etc.).
• A customer-facing Priority and an independent Internal Priority, each requiring its own permission to change.
• A Warranty flag, or a requirement for a source document (an authorized Sales Order) when the request is billable, depending on your company's configuration.
• Service Request reports: a general list, execution time, requests with status and days, requests without movements, and efficiency by status, all filterable by customer, employee, dates and other criteria.
• AI-suggested similar requests and related requests from the same custom module, when your company enables these features.

Key fields

Validations on save

• The Customer is required and can't be voided.
• The Description is required.
• The Short Description can't exceed 100 characters.
• If a Consultant/Technician is set, they must have an email address on file.
• If the request isn't covered by Warranty and your company requires a source document for billable requests, a Sales Order must be provided as the source, and that Order must be authorized (fully or partially).
• If a Transaction Type is set, it must exist in the catalog.
• A voided request can't be edited, and the document number can't be changed once it's been created.
• A "parent" request can't be voided while it still has active "child" Service Requests linked to it; unlink or void the child requests first.

Availability and permissions

• Service Requests are only available on the Enterprise plan, with the Service module active for your company.
• Viewing, creating, editing, deleting and voiding requests requires the "Service Requests" permission in your user group, with its View, Add, Edit, Delete and Void levels.
• Changing the Priority or Internal Priority requires the specific priority-change permission; changing the Group from the board requires the specific group-change permission.
• The Subsidiary filter on the Kanban boards only shows up if your company enables the corresponding feature; otherwise the boards don't support working with a subsidiary or location selected in your session.
• Linking "parent" and "child" requests, the enhanced board with drag-and-drop reordering, customer authorization, and AI-suggested similar requests are all features your company must enable before you can use them.
• Custom status workflows (defining your own status sequences) require the Enterprise plan with the Service module active and the feature enabled; see the Service Request Statuses and Service Request Status Workflows pages to set it up.

Tips and common mistakes