- Intake form and validation
- Rule-based routing
- Role permissions
- Status controls
- Urgent alerts
- Audit history and dashboards
Product requirements document, v1.0
Configurable intake routing and case control.
This document defines the scope, rules, expected behaviour, and release checks for the simulated CommunityConnect platform.
Project scope. I created this portfolio document to practise writing clear requirements for a delivery team. It is not paid client work.
01 / Problem
The current process makes ownership hard to track
Community requests arrive through shared inboxes, phone notes, and disconnected spreadsheets. Staff use inconsistent statuses, routing depends on memory, and supervisors cannot see stalled or urgent work without manual follow-up.
Product outcome: every request has a valid owner, controlled status, protected notes, response target when needed, and traceable history from intake through closure.
02 / Scope
Pilot scope
The pilot covers one region and the core intake lifecycle. It deliberately excludes work that would add risk before the operating model is proven.
- Public self-service portal
- SMS conversations
- Clinical decision-making
- Payment or insurance processing
- Cross-agency data sharing
- Automated record deletion
- 95% correctly routed on first pass
- No unauthorized-note exposure
- 100% closure-field completion
- All urgent requests visible in five minutes
- Imported active-record reconciliation ≥99.5%
03 / Functional requirements
Functional requirements
Create request
Authorized staff can create a request from a single form with requester, contact channel, service category, postal code, urgency, consent, and notes.
Validate intake
The system blocks submission when consent is missing, the postal code is malformed, or a required field for the selected category is blank.
Route ownership
On creation, the system assigns the request using service category plus postal region. Unmatched combinations enter the Triage queue.
Control status
Users can move requests only through the approved lifecycle: New, In triage, Assigned, In progress, Waiting on client, Closed.
Escalate urgency
Urgent requests create a supervisor alert and a response target. They cannot be closed until an escalation disposition is recorded.
Protect notes
Sensitive notes are visible only to the assigned worker and supervisors; general staff see the request summary and current status.
Prevent silent stalls
A daily check flags priority requests that are unassigned, blocked, or past their response target.
Close with evidence
Closure requires a disposition, outcome, final owner, and completed timestamp. Closed records become read-only except to supervisors.
Notify deliberately
The system sends only event-based notices for assignment, reassignment, urgent escalation, and client-response reminders.
Preserve history
Every assignment, status, priority, permission-sensitive note, and closure change is written to an immutable audit history.
Support reporting
Supervisors can filter active volume, aging, response-target breaches, workload, and dispositions by region and category.
Handle migration
Imported records retain their legacy ID, source owner, source status, and migration batch for reconciliation and rollback.
04 / Decision rules
Routing and access rules
ConditionSystem decisionFallback
Category + region matchAssign configured queueTriage queue
Urgent = YesAlert supervisor + start targetSupervisor queue
Sensitive note = YesRestrict to owner + supervisorHide content
Waiting on client ≥3 daysCreate staff reminderFlag aging report
05 / Edge cases
Exceptions the design must handle
- 01
A postal code changes after assignment: rerouting is suggested, not automatic, so an in-progress request is never silently transferred.
- 02
Two submissions share the same requester, category, and contact information within 24 hours: flag a possible duplicate and let Triage merge or keep both.
- 03
An urgent request has no matching regional queue: assign it to the supervisor queue and start the response timer immediately.
- 04
A staff member loses a role while owning open requests: preserve the record history, remove access, and place affected requests in reassignment review.
- 05
A client replies after closure: create a linked follow-up request instead of reopening the immutable original record.
- 06
An import contains an unknown category or invalid owner: quarantine the row with a reason; never coerce it into a valid value silently.
06 / Acceptance criteria
Acceptance checks
Given a complete standard intake, when it is submitted, then it receives a unique ID, the correct queue, New status, and an audit event.
Given an urgent intake with no routing match, when submitted, then it enters the supervisor queue and shows an active response target.
Given a general staff user, when the user opens a request with a sensitive note, then the note content is not returned or displayed.
Given a request without a disposition, when a user attempts to close it, then closure is blocked and the missing field is identified.
Given a duplicate candidate, when Triage chooses merge, then the source IDs remain traceable and no audit history is discarded.
Given an invalid migration row, when the import completes, then the record is quarantined, counted in reconciliation, and excluded from production queues.
07 / Release control
Pilot and rollout checks
- Readiness: signed requirements, permission matrix, routing table, migration reconciliation, and zero critical UAT defects.
- Pilot: one region, named support owner, daily issue review, and manual rollback available for seven days.
- Observe: routing accuracy, breach rate, permission failures, reopen/follow-up rate, and staff task completion.
- Expand: proceed only after operational sign-off and documented fixes for pilot exceptions.