Privacy and request handling
BackflowPath stores contact requests so the team can review the local utility context, answer next-step questions, and follow up on public provider options when useful.
Plain language
What the form data is used for
Requests are used to understand the page that generated the question, review the governing utility workflow, and respond with the clearest next step.
Stored request data
- Name, phone, email, city, property type, issue type, and notes from the form.
- Trusted utility routing fields when BackflowPath can validate the request against a server-issued routing context.
- Submitted utility ID, utility name, page family, source page, and referring page when the browser sends them.
- Assignment records when the team manually matches a request to a public provider profile.
- Storage metadata needed to export or review the request history later.
Official guidance stays separate
- Submitting a request does not change the underlying utility rule.
- BackflowPath keeps official authority guidance and public provider directories separate.
- Requests are stored for review first, even when the page context is verified.
- BackflowPath does not sell or fan out a request through a private dispatch queue.
- If the routing context cannot be verified, the request stays in BackflowPath for manual review.
Storage and review posture
Requests are stored in the file-backed workspace used by this application. Access is intended for internal review, export, and manual follow-up only.
Questions about a stored request should be handled through the reply path used for the submission or through the utility-specific page that generated the request.