1. DevOps Dashboard
  2. Features
  3. Service requests
Feature · Service requests

Service requests

Keep requester, service, due date, and completion state together.

OverviewSubmitted Service Requests
DevOps Dashboard · Service requests

Submitted Service Requests

Approval conditions

New
Request typeRequested atDue atStatusRequesterService
RT-35409 Oct15 OctSubmittedSRV-4588
RT-95126 Oct31 OctSubmittedSRV-2082
RT-91309 Oct16 OctSubmittedSRV-2821
RT-42505 Oct10 OctSubmittedSRV-8511
RT-75321 Oct29 OctSubmittedSRV-4631
6 of 6 records
RT-354Service requests · SR-77010
Submitted
Requested at09 Oct
Due at15 Oct
ServiceSRV-4588
Example screen with sample data

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

Set up DevOps Dashboard your way.

Start free, then use Proto to change fields, steps and approvals before your team goes live.

How to get started