Requests and receipts

A service request records a request type, requester, service and dates for request, due date and completion. It enters submitted status for the Request Approver’s decision. Approved work can move to in progress and completed. A rejected request remains a decision of its own. The Request Fulfiller should see the approved item and its due date before taking action.

Integration receipts answer a different question: what happened to a processing event, including stream registration. The receipt can hold a provider name, external event identifier, receipt time, payload hash and processing status. A Log Operator reviews received, applied, rejected and failed outcomes to discuss a specific event with the sending system. Keep the provider’s event identifier when investigating retries or failed processing.

• Request decision. Submitted work awaits an approver; approved work becomes eligible for fulfillment.
• Fulfillment timing. Requested, due and completed dates let the team review the elapsed interval.
• Event outcome. A receipt records the inbound identifier and processing result for later inspection.

The submitted requests screen is the approval inbox. The Request Approver opens the request, checks the service and requester, then decides whether it may proceed. The Request Fulfiller works from the approved and in-progress screen. For a stream registration, the operator opens the receipt list and checks the exact external event identifier before deciding whether a provider needs attention.

Agree which request types are appropriate for this register and who may request each action. Define the approval authority before the first request is submitted. The record captures the request type as text, so the team should agree its naming and review it regularly. Set realistic due dates and decide who enters the completion date when work is finished.

For receipts, agree how the provider identifies events and what applied, rejected and failed mean in the integration contract. Agree the provider’s transport and replay policy when connecting that system. The operations team should know which outcome needs a retry or an investigation and who contacts the provider when an external event ID cannot be found.

A service owner requests a source configuration change for a service. The requester submits the item with a due date. The Request Approver checks the service and authorizes the request; the Request Fulfiller starts work and records completion when the action is done. Separately, stream registration creates a processing receipt. The Log Operator finds it by external event identifier and sees that processing failed. They use that identifier and provider name to investigate the delivery. A completed request does not change a failed registration receipt into an applied one.

• Submitted requests — Review incoming service requests before approval.
• Request fulfillment — Work approved requests through their due and completion dates.
• Processing receipts — Inspect provider, event identifier and processing outcome.

Use request approval and fulfillment for the decision path and stream registration for the event context.