A rights request workflow people can actually follow

Begin with a clear request form

People should not need to understand internal teams to raise a privacy request. Offer a short request-type list, explain each option and show only the necessary fields. For a correction, list collected information once and let the person describe what needs changing.

Avoid hardcoding a phone correction when someone may need to correct another detail. Keep a place for an explanation, but do not request unnecessary documents or repeat information available through their authenticated account. A small form can still capture an actionable request.

Preserve the person’s identity

Use the original account’s user ID as the stable reference. Display name and email when available so staff can recognise the person, without treating a missing display field as a missing account. Keep the request attached to the correct organisation and prevent a client from looking up another organisation’s records.

Where a representative is involved, show both the original person and who submitted the request. A verified nominee email should not overwrite the original student’s identity. Approval and authority to act require their own checks and organisational review; an email verification code alone does not establish authority for every action.

Route the work, not just the notification

Use the fulfilment settings to assign a responsible contact by request type. Show that contact in the request view rather than asking staff to assign an owner again unnecessarily. An internal target helps the team manage its work, but should be clearly distinguished from any applicable legal requirement.

Keep the newest requests easy to find and provide filters for type, status and date. Pending work that is still within its target is different from overdue work. Useful filters help staff decide what needs attention without forcing them to infer urgency from a long, unsorted table.

Close with the real result

For a manual correction, the administrator changes the record in the operational application first. They then use Report manual completion in SecureLay and describe the change. For an erasure, the responsible team performs the reviewed deletion work before recording its result. Submitting a request through an API does not perform either action by itself.

Explain if work cannot be completed as requested, and let the person follow the status. Test submission, assignment, action and completion. The workflow succeeds when both sides understand the outcome, not simply when the dashboard counts one fewer open case.