Documenting revocation (workflow)
Revocations happen. What matters is that later you can trace what happened, when — and which project it belongs to. This page is not legal advice, but practical guidance for a calm process.
Translator: In LegitForm we think of revocation as a change to a shared approval (Living Consent) — visible to both sides and documented in the history. Learn more.
Why this matters
- So it’s clear in the team: which state applies.
- So later you don’t have to guess why something was removed.
- So “received” vs “finalized” vs “revoked” stays traceable.
Practical flow (without drama)
- Find the consent in the right project.
- Mark the status as “revoked” (with date/note if needed).
- If content is already published: clarify internal tasks (remove/unlist/archive).
- If needed: export proof/protocol so the history stays documented.
What you should capture in the documentation
- Project/occasion
- Time (when it was revoked)
- Scope (what it was about)
- Note (e.g. “person no longer wants social publishing”)
Can I document a revocation?
Yes. What matters is a traceable history: what happened, when, and which project it belongs to.
Do I have to delete everything?
That depends on the case. Practically, it helps to document the status and clarify next steps internally.
What about already finalized proofs?
The history remains traceable. You can document revocation/changes and export if needed.
What’s the best workflow?
Find the consent in the project → set status/note → adjust/remove content if needed → keep the history traceable.
Is this legal advice?
No. This is practical guidance.