# Privacy Request Flow Copy Review Workflow in Figma > Review access, correction, deletion, and data export request copy across Figma so users understand scope, identity checks, timing, and consequences. - Canonical page: https://www.hypermatic.com/articles/copydoc-privacy-request-flow-copy-review-workflow-in-figma/ - Published: 2026-09-18T00:00:00.000Z - Updated: 2026-09-18T00:00:00.000Z Privacy request flows turn legal rights into interface decisions. A user may want a copy of their data, correction of inaccurate information, deletion, restriction, or another region-specific action. If the copy is vague, the flow creates anxiety at exactly the moment the product needs to be precise. [CopyDoc](/copydoc/) helps teams export, review, update, and re-import Figma text through spreadsheets and other content formats. That makes it easier to inspect the whole request journey rather than approving isolated screens one at a time. ## Map the request families and jurisdictions Do not begin with one generic "privacy request" modal. Build a matrix of request type, eligibility, required information, identity verification, response timing, exceptions, output, and owner. Common request families include: - access to personal data - portable data export - correction of inaccurate data - deletion or erasure - objection or restriction - consent withdrawal - appeal or complaint The available rights and required wording vary by jurisdiction and product context. Legal counsel should define the rules. Content design should make those rules understandable without overstating what the company will do. This article is distinct from the [account deletion copy workflow](/articles/copydoc-account-deletion-copy-review-workflow-in-figma/), which focuses on closing an account and its product consequences. A privacy request may affect selected data while the account stays active, and it often includes verification, case tracking, and formal response steps. ## Export the complete journey Use CopyDoc to bring the relevant Figma text into a reviewable table. Include the entry point, request chooser, eligibility explanation, identity check, form labels, confirmation, pending status, requests for more information, completion, partial refusal, appeal, email notifications, and support documentation. Add columns for screen or component, request type, jurisdiction, state, owner, legal approval, implementation key, and notes. Preserve stable IDs so reviewed text can return to the correct layer. Reviewing in a spreadsheet exposes contradictions that are hard to see across frames. One screen may promise completion "within 30 days" while an email says "up to 45 days." A button may say "Delete all data" even though the following explanation lists legally retained records. ## Explain identity checks without sounding accusatory Identity verification protects the user, but unexplained checks can feel obstructive. State why information is needed, how it will be used, whether it will be retained, and what alternatives exist when the standard method fails. Compare: > Upload ID to continue. with: > To prevent someone else from accessing your data, we need to confirm your identity. Choose a verification method below. The second version connects the burden to a user benefit. It still needs accurate supporting detail and a path for users who cannot complete the default check. ## Separate request, account, and data consequences Users need to understand what changes now, what happens after approval, and what may remain. Avoid absolute language unless the system and policy can honor it. For a data export, explain the included date range, file format, delivery method, expiration, and any categories delivered separately. For correction, distinguish editable profile data from records that require review. For deletion, explain account access, active subscriptions, shared work, backups, financial records, and recovery windows with approved wording. Use specific buttons: "Request my data," "Submit correction," or "Continue to identity check." A generic "Confirm" forces users to remember the consequence from the previous paragraph. ## Review exceptional states as first-class copy The happy path is rarely the difficult part. Include designs and text for: - request already open - identity could not be verified - more information required - request paused by the user - request partly fulfilled - request declined with a reason category - download expired - delivery failed - account controlled by an organization - child or authorized-agent request Each state should say what happened, what the user can do, and where to get help. Avoid exposing internal risk rules or sensitive security details. The [error message and empty state workflow](/articles/copydoc-error-message-and-empty-state-review-workflow-in-figma/) provides a broader approach to recovery copy. Privacy flows add formal timing, rights, and case-status obligations. ## Check consistency beyond Figma Compare the approved strings with the implemented product, privacy notice, request portal, automated emails, support macros, and agent scripts. Standardize names for the same concept: "data request," "privacy request," and "subject request" should not rotate casually if users must recognize their case later. Test long names, translated text, reference numbers, dates, file sizes, and mobile layouts. Read the flow with a screen reader and confirm that headings, field instructions, validation, status updates, and focus order make sense without the visual design. Before signoff, verify that every request type has an owner, eligibility and exceptions are accurate, verification is explained, timing language is consistent, consequences are explicit, exceptional states are written, and every final string has been reconciled with implementation. CopyDoc makes the language easier to review as a governed system. The team still needs legal judgment and operational proof, but it no longer has to hunt through dozens of Figma frames to discover that the same privacy promise was written four different ways.