Service name
Money to Prisoner
Service environment
Impact on the service
The Emails application of Money to Prisoner receives callback data from GOV.UK Notify whenever an email or SMS changes status (for example, delivered, failed, bounced, or permanent failure). This callback data is currently written to Azure Application Insights for monitoring and operational visibility.
We are re-platforming the Money to Prisoner suite of apps (which is currently python based and 10+ years old) to realign it with HMPPS standards, as such we have been working on the callbacks feature and Azure data posting.
We need to understand whether this telemetry is being actively used, monitored, queried, or maintained by another team within MoJ/HMPPS. This information will help us prioritise and assess the impact of any future changes to the callback implementation, data structure, retention, or logging approach.
Without this understanding, there is a risk that changes could inadvertently affect reporting, monitoring, dashboards, alerts, or other consumers of the Application Insights data, or that we make an incorrect prioritisation decision.
Problem description
The Emails Service receives callback notifications from GOV.UK Notify containing message delivery status information for emails and SMS messages sent by MTP applications.
Examples include confirmation emails sent when a user performs an action such as sending money to a prisoner. GOV.UK Notify posts delivery status updates back to the Emails Service via a callback endpoint. The service validates the payload and:
Logs callback data to Azure Application Insights.
Returns a 204 No Content response when the callback is processed successfully.
Returns a 400 Bad Request response if the payload cannot be validated or parsed.
We would like to understand:
- Who may currently consume or rely on callback data has been produced.
- The purpose for which each identified consumer uses callback data; including any operational, reporting or monitoring requirements.
- Any existing sources of callback data usage e.g. application code, dashboards, logs, documentation and stakeholder knowledge.
- Any risks, dependencies or impacts associated with changing or removing the callbacks feature have been documented.
This will enable us to provide our Service Owner with a recommendation outlining whether redevelopment of the callbacks feature should continue, be amended, or be deprioritised based on the findings.
Contact person
Oscar Petherick (Product Manager - Send Money to Prisoner)
Slack: Oscar Petherick
Oscar.Petherick@justice.gov.uk
Service name
Money to Prisoner
Service environment
Impact on the service
The Emails application of Money to Prisoner receives callback data from GOV.UK Notify whenever an email or SMS changes status (for example, delivered, failed, bounced, or permanent failure). This callback data is currently written to Azure Application Insights for monitoring and operational visibility.
We are re-platforming the Money to Prisoner suite of apps (which is currently python based and 10+ years old) to realign it with HMPPS standards, as such we have been working on the callbacks feature and Azure data posting.
We need to understand whether this telemetry is being actively used, monitored, queried, or maintained by another team within MoJ/HMPPS. This information will help us prioritise and assess the impact of any future changes to the callback implementation, data structure, retention, or logging approach.
Without this understanding, there is a risk that changes could inadvertently affect reporting, monitoring, dashboards, alerts, or other consumers of the Application Insights data, or that we make an incorrect prioritisation decision.
Problem description
The Emails Service receives callback notifications from GOV.UK Notify containing message delivery status information for emails and SMS messages sent by MTP applications.
Examples include confirmation emails sent when a user performs an action such as sending money to a prisoner. GOV.UK Notify posts delivery status updates back to the Emails Service via a callback endpoint. The service validates the payload and:
Logs callback data to Azure Application Insights.
Returns a 204 No Content response when the callback is processed successfully.
Returns a 400 Bad Request response if the payload cannot be validated or parsed.
We would like to understand:
This will enable us to provide our Service Owner with a recommendation outlining whether redevelopment of the callbacks feature should continue, be amended, or be deprioritised based on the findings.
Contact person
Oscar Petherick (Product Manager - Send Money to Prisoner)
Slack: Oscar Petherick
Oscar.Petherick@justice.gov.uk