Requests and receipts

A service request names the requester and service. The request type, requested date, due date and completion date help the Request Coordinator understand the work and its timing. Its status moves through Submitted, Approved, in progress, Completed or Rejected. These are service request decisions. They should not be confused with approval of a change or verification of a patch attempt.

Integration receipt records hold a provider, external event ID, received time and payload hash when the team records an event. The receipt status distinguishes Received, Applied, Rejected and Failed. This gives Admin a place to review recorded event details. The event’s presence is not itself an installation result; an asset-specific result is recorded on a patch attempt.

• Request context. Requester and service link a request to the person asking and the affected operation.
• Timing. Requested, due and completion dates help the coordinator review open and finished work.
• Event receipt. Provider identity and external event details help Admin investigate intake exceptions.

Agree which requests the service team will record and who may approve them. Define how request types are named so the coordinator can group similar work. Decide when an approved request leads to a change review and who supplies that change’s summary, risk, window and rollback plan. The team reviews the request, service change and asset-specific attempt together before closing patch work.

For connections, agree who owns each provider and how external event IDs are handled. A receipt marked Rejected or Failed should reach someone who can investigate the source and the intended effect. Review the provider’s record before repeating an event. If a feed supplies patch data, the team still checks the catalog identity and planned asset before an attempt begins.

Create a request for a named service and requester. Move a Submitted request through a decision, then record the work and completion time. Confirm a rejected request remains visible with its original requester and service context. In a separate case, inspect a failed integration receipt with its provider, event ID and received time. The Admin should be able to distinguish a receipt failure from a failed installation attempt.

Use a patch request that results in planned installation. The Request Coordinator reviews the request, the Change Manager records the service change decision, and the Patch Operator records the attempt on the selected asset. Read the three records in order before closing the request. Their different statuses show which decision or action each person completed.

• Requests awaiting decision — Review submitted requests by requester, service and due date.
• Receipt exceptions — Find rejected and failed integration events for investigation.

Handle a service request and review the change.