Service Requests

A service request has a requester, service, request number and type. Its requested and due dates help the team place it in the operating cycle. The request approver sees submitted work in a dedicated inbox and decides whether it may proceed. Approval moves the request into progress for authorized fulfillment. A rejected request remains a recorded decision rather than disappearing from the queue.

The request type is free text. During setup, agree how the team describes common database requests so the approver can interpret them consistently. The service link identifies the operational area affected, while the requester link identifies the person who asked. Neither should be inferred solely from an email subject or an unverified integration event.

• Submission. The request number, type, requester and service explain the proposed action.
• Approval. The approver chooses an approved or rejected outcome for submitted work.
• Fulfillment. An approved request moves through work in progress to a completed record with its completion date.

Decide which requests need the request approver and what information must be present before that person decides. Agree who updates due dates and who carries out approved work. The service manager should make clear how a request differs from an incident: a requested action follows approval, while a service interruption needs response and investigation. Both may relate to the same service, but their status values and decisions are different.

Before accepting live submissions, map each requester to a person record and ensure the relevant service exists. Give request approvers access to the submitted queue and ensure fulfillment staff can see the approved work they are expected to handle. Rehearse a rejection as well as an approval so staff know what the requester will find in the record.

A requester asks for a database-related service action. The team records a request number, type, requester, service and requested date, then sets the due date. The request approver opens the submitted inbox, checks the scope and either approves or rejects. On approval, the request moves into progress for the service manager, who records the completion date when work finishes.

The handoff can be checked from the request record itself: the requester and service remain visible while status changes. If the request was rejected, do not mark it in progress. If the underlying issue is an outage, create an incident against the affected service and asset instead of using a request status to describe investigation.

• Request Approval Inbox — Submitted requests waiting for an approver’s decision.
• Service Request Queue — Approved and active work with requester, service and due date.

See request approval and fulfillment and incident handling.