Privacy and Compliance Request

Privacy and compliance requests should be handled with clear ownership and safe records.

Submit a request

1. User opens the public Motornauts form or the tenant-routed public form supplied by the service center. The tenant route is still public: it does not sign the user in or confirm a tenant customer record.
2. User selects the closest request type: access, correction, restriction, erasure assessment, consent/objection, notice/question, support privacy, account-security privacy, incident intake, or other privacy.
3. User provides an optional name, a reachable email address, and a concise description.
4. User avoids passwords, OTPs, payment card data, private links, or full documents.
5. User completes bot verification and submits once. If verification is unavailable, use the published email link.
6. A fixed success message confirms receipt without showing a public request ID or promising identity verification, deletion, fulfillment, a legal outcome, or a response deadline. A fixed failure message retains the safe form values for retry but exposes no backend or provider diagnostics.

Coordinate a request

1. A Tenant Admin with compliance-request read permission opens Compliance requests. Branch Manager and Service Advisor accounts do not receive this tenant compliance workspace; do not broaden their role as a workaround.
2. Filter by one status, request type, owner, or a bounded requester/summary search. Counts describe the complete server-filtered scope while the table is paginated. If filters are invalid, clear them before retrying; Motornauts does not load partial case data.
3. Open a case by its human requester and request-type label. Treat Internal target as a coordination aid, not a final statutory deadline.
4. Motornauts support may classify request type, owner, and data role before tenant disclosure when needed.
5. Tenant Admins update coordination notes without recording secrets. The status choices shown are the only tenant coordination transitions currently offered by the server.
6. Tenant coordination can move non-terminal work states only; closed and invalid/spam cases remain read-only.
7. Keep notices and decisions tied to the request record. A “showing N of total” notice means older evidence is not represented on that page.

If access, the case, or verified evidence is unavailable, stop and refresh rather than inferring a customer, tenant, or case from a URL. Do not copy opaque URL values, request IDs, provider details, or backend error text into support messages.

Fulfill or export safely

1. Confirm the request is verified, in progress, tenant-coordinated where needed, and free of unresolved legal caveats before any final action.
2. Record a fulfillment entry for access/export, correction, restriction, erasure assessment, consent withdrawal/objection, or refusal.
3. Use export bundles for safe disclosure. A Ready bundle requires a durable subject binding and must exactly match the approved access-fulfillment category scope. The implemented canonical categories are request and events; broader customer, workshop, fleet, staff-activity, payment, document/media, or service-history categories remain review-needed until an ownership-safe projector exists. JSON and CSV use the same selected category projection and exclude internal notes, staff-only handoff details, provider callback details, private document links, token/hash material, decrypted payloads, and secrets.
4. Record decisions for correction, restriction, erasure assessment, and consent withdrawal/objection only against verified request targets. Immutable records such as invoices, audit logs, payment callback evidence, inventory ledgers, generated artifact versions, ownership history, repair-order status events, and estimate approvals must not be silently rewritten.
5. For refusals, record the reason and appeal placeholder on a formal refusal fulfillment. Keep review-needed, provider-readiness, and draft/non-final caveats unresolved until Motornauts support confirms they are clear.

Plan retention or restricted delete

1. Create a retention plan from the compliance request before taking a restricted delete, anonymization, hold, refusal, or verification action.
2. Add verified targets and keep blockers visible when there is an active repair order, non-terminal invoice or payment, legal hold, fleet or ownership dependency, generated artifact dependency, backup caveat, provider caveat, or immutable evidence record.
3. Use an executed legal-hold action to activate a hold for the exact tenant and target. The hold applies across later retention plans, and the target displays Active legal hold. A release succeeds only while that hold is active.
4. Record a safety check before final execution. Blocked or review-needed checks should preserve the blockers instead of clearing them.
5. Treat plan status as planning and approval evidence. Execution and verification are recorded through target actions; a newly created plan cannot claim that mutation work is already executed or verified.
6. Record retention actions only after tenant approval, legal-basis, backup, provider, and support-review gates are satisfied. Tenant Admins can coordinate draft plans, safety checks, and approval notes. The tenant workspace never exposes retention execution; final destructive execution and verification require the separately guarded platform workflow and may require Motornauts support review.
7. Automated anonymization currently covers terminal staff invitations, reviewed self-registration requests, resolved/spam support aggregates, and complete terminal notification aggregates. Notification attempts, SMS rows, and email rows cannot be anonymized as standalone targets because their parent relation can re-identify them. Active rows and active notification/reminder/feedback dependencies remain blocked.
8. Generic marker soft delete, RESTRICT, global CustomerProfile mutation from tenant scope, direct notification-child anonymization, provider-account deletion, unsupported object targets, and any target/action pair without a model-specific safety handler stay explicitly blocked. VehicleDocument, InspectionMedia, and GeneratedArtifact object deletion requires an approved platform execution with final backup/provider evidence; it remains EXECUTING until the worker verifies primary-storage absence and records executed evidence. Do not treat primary deletion as backup purge.
9. A supported final mutation reloads and locks the in-progress request, exact approved plan, clear target, and shared hold state. Hold/release transitions, mutation or state change, action evidence, and sanitized audit entry commit together. If a hold is active or any other gate changes, the whole operation fails without a completed action.
10. Notification and support aggregate anonymization is irreversible, and the retained anonymized root evidence cannot be hard-deleted. New notification attempts, SMS/email rows, reminders, feedback links, resends, parent recreation with the original idempotency key, and support status-event/email child data are rejected after the relevant aggregate is anonymized.
11. Verify customer-visible and staff-visible access after a restriction, soft delete, or anonymization. Invoice records are restriction-only/immutable for destructive retention actions and should not be soft-deleted or anonymized. An active hold blocks mutation; it does not prove that provider copies or backups were physically purged.

This guide is operational guidance, not legal advice.

The request detail groups records under Work completed, Exports, Decisions, and Retention plans. These simpler headings do not change the displayed evidence status, legal-basis qualification, hold, approval, provider or backup requirements. Request actions record permitted plans and decisions; the tenant workspace still does not execute data deletion.