Revoking or closing a consent request

What this article covers

Consent Requests is the inbox where your network HQ (your franchisor or association) asks, by name, to show your data somewhere more specific than the anonymous-aggregate default: a leaderboard, a specific metric view, a case study, a deep-data drill-down, or an Item 19 cohort. Consent Requests: your data-visibility inbox and Asks awaiting your response cover the inbox itself and how to approve or decline a pending ask.

This article covers what happens after you have already answered: changing your mind on something you approved, what an expiry date actually does, and how a request that closed without your ongoing involvement (declined, withdrawn, or expired) behaves when you open it again.

Where to find it

Open Consent Requests from the sidebar, or go straight to /consent-requests. A request you already approved sits in the Recently resolved row (or, if it is more than 30 days old, it has aged off that row entirely, though the approval itself still stands). Click its tile to reopen the same response window you used the first time.

Revoking a previously approved request

Reopen a tile for a request whose status is approved and the window shows a short confirmation line: "You approved this on [date]. You can revoke at any time; HQ stops seeing your name immediately after." Below it sits a single control:

• Revoke reason (optional), a plain text field for why you are changing your mind.
• Revoke approval, the button that carries out the revocation.

1. 1Reopen the approved request's tile from Recently resolved.
2. 2Optionally type a reason in Revoke reason. This is not required. Whatever you type here is written to the request's internal audit log alongside your identity and the time, so HQ has a record of why you pulled back, even though the app itself does not display that reason back to you afterward (more on that below).
3. 3Click Revoke approval. The action applies immediately: the request's status flips from approved to withdrawn, and the modal closes.

The moment you click Revoke approval, your name comes off that specific ask. That is what "HQ stops seeing your name immediately" means in practice: from that point forward, that leaderboard, metric view, case study, deep-data scope, or Item 19 cohort no longer carries your identity, and your data reverts to the anonymous-aggregate default everywhere else on the platform, exactly as if you had never approved it.

The Item 19 cohort case

If the request you are revoking is an Item 19 cohort ask, revoking does one more thing behind the scenes: it flips your entry in that cohort's opt-in roster from opted-in back to withdrew. Your row stays in that roster rather than disappearing, since franchise disclosure filings need a record of who was in and who withdrew, not just who is currently in. Practically, this means your anonymized financial-period and jobs facts drop out of the next percentile calculation for that cohort, without erasing the fact that you were once part of it.

Your revoke reason is not shown back to you later

Whatever you type into Revoke reason is recorded (it travels to HQ's audit trail on the request), but the read-only view you see when you reopen a withdrawn request afterward does not redisplay it. The closed-request note only ever echoes back a decline reason, not a revoke reason or an HQ-initiated withdrawal reason. If you want to remember why you revoked something, keep your own note; Verinode will not show it to you again inside this window.

Expiry: what happens if HQ set a deadline and you never respond

Some requests carry an expiry date, set by HQ when they sent the ask. Where you see it:

• On a pending tile's meta line, as a countdown: "expires today," "expires tomorrow," "expires in N days" under a month, or "expires in N months" beyond that. A request with no expiry reads "no expiry".
• Inside the response window, as a plain date under Expires, if HQ set one. No Expires row appears at all if HQ left it open-ended.

If the expiry date passes while a request is still pending, meaning you never approved or declined it, the request closes on its own with a status of expired. You do not need to do anything for this to happen, and nothing about your visibility changes when it does: an expired request never reached "approved," so your data was never shown by name under it in the first place. An expiry lapsing is functionally the same outcome for your data as a decline, the difference is only that nobody, you included, made an active choice.

An expiry date only matters while a request is pending. Once you have approved a request, its own expiry field stops being the thing that ends it, only you (with Revoke approval) or HQ pulling the ask back can close an approved request from that point on.

How declined, withdrawn, and expired requests close

Three statuses share one behavior: declined, withdrawn, and expired are all closed and read-only. Reopen any of their tiles and the window shows one line: "This request is closed. No further action needed." If you declined the request with a reason, that reason appears alongside it: "Your reason: [your text]." There are no buttons, no fields, nothing left to do.

A few things worth knowing about how a request lands in each of those three states:

• Declined always means you said no while it was pending, using the Decline button and its optional reason field.
• Withdrawn can come from either side. It is the status an approved request flips to when you click Revoke approval. It is also the status HQ's own tooling can set directly, on a request that is still pending or already approved, if HQ pulls the ask back themselves before or after you responded. The request's internal audit log distinguishes the two (your action is tagged as coming from you, an HQ pullback is tagged as coming from them), but the closed-request view you see does not surface which side triggered it, only that it is closed.
• Expired always means the request's deadline passed with no response from you, as covered above.

Best-practice example

Say you approved a Named leaderboard ask three weeks ago, putting your net margin number next to your name at your franchisor's request. You have since decided you would rather not have that figure attached to your name going forward. Open the tile from Recently resolved, type a short reason such as "prefer to stay anonymous on margin going forward," and click Revoke approval. From that moment, your name comes off that leaderboard line, and your net margin reverts to the anonymous-aggregate pool like every other metric you have not separately approved. The one thing revoking will not do is pull back a snapshot of that leaderboard your franchisor already screenshotted for a conference deck last week, which is why the moment you decide to revoke is the moment to actually click the button.

Separately, say a Case study ask sat pending for 60 days with a 60-day expiry and you never opened it. It closes on its own as expired. Nothing was ever shared under it, and if your franchisor still wants to feature you, they will need to send a new ask.

Related reading

• Consent Requests: your data-visibility inbox
• Asks awaiting your response
• Recently resolved requests
• Benchmarks overview
• How benchmarks work