These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- DevOps Dashboard
- Features
- Service requests
Service requests
Keep requester, service, due date, and completion state together.
OverviewSubmitted Service Requests×
DevOps Dashboard · Service requests
New
Submitted Service Requests
Approval conditions
| Request type | Requested at | Due at | Status | Requester | Service | |
|---|---|---|---|---|---|---|
| RT-354 | 09 Oct | 15 Oct | Submitted | SRV-4588 | ||
| RT-951 | 26 Oct | 31 Oct | Submitted | SRV-2082 | ||
| RT-913 | 09 Oct | 16 Oct | Submitted | SRV-2821 | ||
| RT-425 | 05 Oct | 10 Oct | Submitted | SRV-8511 | ||
| RT-753 | 21 Oct | 29 Oct | Submitted | SRV-4631 |
6 of 6 records
RT-354Service requests · SR-77010
SubmittedRequested at09 Oct
Due at15 Oct
ServiceSRV-4588
What you can do
Work the request against its due date
A service request records the request type, requester, related service, requested time, due time, completion time and status. The service desk manager can see active work in one queue and compare completed work with the date it was due. A submitted request should have enough context for the person taking it to understand which service is involved and what the requester needs.
For example, a requester asks for a service action before a planned change window. The manager checks the request type and due date, decides who will carry the work and keeps the record current as it progresses. The request’s final completion time is useful only when the work has actually finished. The workflow applies the completion transition when a request is completed.
How the work is organized
- Intake. Submitted work identifies the requester, requested type and service.
- Progress. Approved and in progress states show work moving through the queue.
- Completion. The completed state and completion time support a review against the due date.
What to agree during setup
Agree which request types the team accepts and how each one maps to a service. Decide who assigns due dates and what information a requester must provide. Clarify the handoff between the requester and the service desk manager when a request is rejected. If approval is part of the local operating policy, identify the person who decides and keep the approved state aligned with the actual decision.
The request status should describe the real work. A request marked Approved is ready to progress; it has not been completed. A rejection should keep the requester’s original submission available for later review. A due date is a planning commitment, and the completion date provides the evidence needed to tell whether it was met.
Check the handoff on an actual case
Create a request tied to a service and a named requester. Confirm that it appears in Active Service Requests with its due time. Progress the request and then complete it. Check that the workflow applies the completed state and that the completion time can be compared with the due time in the request report. Review a second case that is rejected and verify that it no longer appears in the active queue.
At a daily handoff, the manager should be able to distinguish submitted work from work already in progress. A service owner can inspect the underlying service record when several requests concern the same service. The request remains the record of what was asked and when it was finished.
What your team sees
- Active Service Requests — Submitted, approved and in-progress requests with due dates.
- Submitted Service Requests — Newly submitted work ready for the desk manager to review.
Follow the work through
Use the service request process to rehearse intake, progress and completion.
What it keeps track of
Data model- Service requests
- Service Requests records for IT service and asset operations.
- Services
- Services records for IT service and asset operations.
- People
- People records for IT service and asset operations.
Who uses it
Permissions- Service Desk Manager
- , Admin.
Set up DevOps Dashboard your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.