Consent requests: HQ asks awaiting an operator's yes

What a consent request is

A consent request is the one place HQ has to ask before it sees something. Everywhere else on the platform, HQ works with aggregates and rankings that never name a franchisee. A consent request is the explicit, revocable exception: HQ asking one specific operator for permission to name them on a leaderboard, show a metric for them in a particular view, feature their numbers in a case study, or open job-level detail for a specific initiative. Nothing behind that ask is visible until the operator says yes, and the yes only ever covers what was actually asked for.

You author the ask itself from Broadcast → Consent, covered in Consent requests: when a name or private figure can appear. This article is about what happens once you've sent it: the row that ask becomes on Decisions and Action Plans, the governance track it moves along, and why that track is the mechanism that keeps HQ on the right side of the privacy boundary.

Where it surfaces

The instant you click Send request on the Broadcast composer, the record exists in the network data, and it appears as a row on two HQ boards, both reading the same table live:

| Board | URL | What it shows | |---|---|---| | Decisions | hq.verinode.ai/decisions | Every request still pending, plus any request of any status that changed in roughly the last three months. This is where an unanswered ask lives. | | Action Plans | hq.verinode.ai/actions | Only requests an operator has approved. A pending, declined, or withdrawn request never appears here, it isn't in-flight work yet. |

There's no separate "Consent Requests" page inside either board. A consent request is one of four row sources Decisions and Action Plans blend into a single log, alongside decision plans, the intervention queue, and program audits and violations. See HQ Decisions: the franchisor inbox and Action Plans: the network work in flight for how the other three sources fit alongside it.

Nothing about sending or withdrawing a request has a separate publish step for these boards. Withdraw it from either surface, or from Broadcast → Consent, and the same underlying row updates everywhere it's read.

The four kinds of ask

Every request carries a request kind, set when HQ creates it:

• Named leaderboard, permission to show the operator's real name attached to a ranking position instead of an anonymized slot.
• Named view, permission to show one specific metric for that operator by name in a defined view.
• Case study, permission to feature the operator's numbers in a written case study.
• Deep data, the broadest ask: permission to see job-level detail behind a specific initiative.

A fifth kind, item19_cohort, exists behind the scenes for Item 19 disclosure invitations (see Item 19 basics). Those requests carry a standard rationale about the franchise disclosure document and a fixed metric set (annualized revenue, gross margin percentage, annualized job count, claims volume), and they surface on these same two boards exactly like any other consent request, since they write to the same table.

Every request also carries the metric keys it covers and the rationale you wrote explaining the ask. Both travel with the row wherever it's shown.

Reading the row

On Decisions, a consent request tile carries:

• A domain glyph instead of an entity logo. Franchisees don't have a logo the way a vendor or carrier does, so the icon is the business-area watermark instead.
• The title, your rationale text, verbatim. If a request somehow has no rationale on file, the title falls back to the plain label "Consent request."
• The operator's name, anonymized by default (more on this below).
• A status pill in one of four colors, amber Pending, green Acted, teal Parked, or grey Ignored.
• A date, when the request was first sent.

Every consent request row is tagged with the business-area domain Governance, and it always carries Info severity, Verinode's lowest tier. A request waiting for a response is routine, not a flagged problem, so it never picks up the amber or red shading a disputed audit or an escalated violation can. Once your board spans two or more business areas, a domain dropdown appears above the gallery; picking Governance narrows the list to consent requests only.

Consent requests never carry a dollar-impact figure. That field simply doesn't populate for this source.

The status track: Sent → Approved → Closed

Consent requests carry their own lifecycle underneath, five states in the network data: pending, approved, declined, withdrawn, expired. Decisions and Action Plans project every source into one shared tile-status vocabulary so the board reads consistently no matter which of the four sources a row came from:

| Request status | Tile status | What it means | |---|---|---| | Pending | Pending | Sent, waiting on the operator. Nothing is disclosed yet. | | Approved | Acted | The operator said yes. The scoped disclosure is live, and the row now also appears on Action Plans. | | Declined | Ignored | The operator said no. HQ can send a new, differently scoped request later, but this one is closed. | | Withdrawn | Ignored | Either HQ or the operator pulled it back. Whatever was disclosed under it, if it had already been approved, stops the moment it's withdrawn. | | Expired | Parked | An expiration date passed with no response. The tile still reads Parked, not "Expired", because that's the shared bucket the board uses for a timed-out row. |

A closed consent request always lands in Ignored or Parked. It never reaches Resolved, the status other sources (a completed decision plan, for instance) can carry.

Once a request is approved, it also appears on Action Plans, where it draws against a three-checkpoint timeline built specifically for this source:

1. Sent, day 0, always marked complete the moment the row exists.
2. Approved, marked complete the day the operator actually said yes. Until then this checkpoint sits open.
3. Closed, drawn three days after Approved on the timeline, but with no completion condition behind it at all. There is no action anywhere on the platform, HQ-side or operator-side, that flips this checkpoint to done.

That last point matters if you're reading the Gantt: an approved consent request will sit with its "Closed" checkpoint permanently open, usually showing overdue coloring once its target date passes. That's expected, not a stuck row. Verinode doesn't track a separate "close-out" action for a consent grant, because there isn't a "done" state for an ongoing named-view or leaderboard placement while the grant remains in force. The way you close the loop on a live grant is withdrawing it once it's no longer needed, which is exactly the one control HQ retains. For the full mechanics behind how this checkpoint set is built and drawn, see How the Action Plans timeline is built.

Declined, withdrawn, and expired requests drop off Action Plans entirely. Only an approved request was ever "in flight" work, so only an approved request appears there.

The buttons: what HQ can and can't do

This is the one place the platform's read-only posture toward operator data shows up most directly in the controls themselves:

• Ignore is the only action button that ever appears on a pending or approved consent-request tile, and it performs a withdraw, not a dismiss. Clicking it pulls the request back. A pending ask stops waiting on the operator; an approved one immediately revokes whatever was disclosed under it.
• Act and Not now never appear as live buttons on a consent-request tile, in any status. Approving or declining is the operator's call, made from their own IQ deck. HQ has nothing to approve on an operator's behalf, so there is no Act button here to click.
• Once a request reaches Ignored (declined or withdrawn) or Parked (expired), there is nothing left to do with it. There's no Ignore button on a request that's already closed.
• Discuss stays available on every row, in every status, opening the AI agent panel with the request's context loaded so you can talk through next steps or draft a follow-up to the operator.

Clicking anywhere on the tile body, not a button, opens the request in the workspace slider for a closer read without changing its status.

Inside the slider

Opening a consent-request row loads a focused workspace view with:

• The rationale as the header title, the same text shown on the tile.
• A Metrics line listing the specific metrics the request covers, when any are attached.
• The operator's name, anonymized the same way it is on the tile.
• The dates: when the request was sent, and, for approved, declined, or withdrawn requests, when it was resolved. An expired request carries only its original send date, since expiring is a passive timeout rather than an action anyone took.

Panels other decision sources populate, a peer-benchmark comparison, an AI recommendation, a structured multi-step plan, don't apply here and simply don't render. A consent request doesn't carry that kind of evidence, so there's nothing broken about an otherwise plain view.

The privacy boundary this mechanism protects

A consent request always names a specific operator, which is exactly the kind of disclosure the platform normally shields. Two safeguards apply on top of the approval itself:

Names are anonymized by default. Unless your network's entity model is set to Same entity (one legal entity operating every location, under Settings → Data posture), the operator's real location name is replaced everywhere on these boards with a stable label like Franchisee #A1B2, on the tile, in search, and inside the slider. Only an admin can flip that setting, and it only makes sense for a single-entity, multi-location operation, not a network of independently owned franchisees.

The grant is scoped to exactly what was asked, nothing broader. Approving a "deep data" request doesn't hand HQ a general window into that operator's business. It grants exactly the metrics, kind, and time window named on the request, and only those. This board never reaches into an operator's job files, invoices, or claims to build a row: everything behind a consent-request tile, the rationale, the metric list, the status, the timestamps, comes from the network data, a record your own HQ admins write to when they send an ask. The one moment an operator's own data posture changes is their approval, and even then, what surfaces elsewhere on the platform is bounded to the scope they actually granted.

Franchisees grant. HQ asks and, if it changes its mind, withdraws. HQ never takes.

Empty states

If no rows match the current filter on Decisions, the gallery shows a plain message instead of an empty grid:

• Status filter on All, nothing on the board at all: "No decisions for you yet. They'll land here as Verinode spots cost savings, risk, and growth opportunities in your data."
• Any other status selected, nothing in that state: "Nothing [pending / acted / parked / ignored / resolved] for you right now."

Filtering to Governance with nothing pending shows the same generic "Nothing pending for you right now" line, there's no message written specifically for consent requests.

On Action Plans, an approved consent request with no other in-flight rows around it doesn't get its own empty-state copy either. The board's stage-filter empty states ("Nothing overdue," "Nothing due today," and so on) describe the timeline bucket, not the source, since a consent request's Closed checkpoint is what typically lands it in Overdue once its target date passes.

How to work this list

1. 1Open Decisions, set the status filter to Pending, and narrow to Governance once your board spans multiple business areas. That combination is the fastest way to see every ask still waiting on an operator.
2. 2Check the date on each pending tile. A request sitting for several days with no response is your cue to follow up with the operator directly, HQ cannot nudge the approval along from inside the platform.
3. 3Once a request moves to Acted, check Action Plans to see it on the timeline. Its Closed checkpoint will typically read as overdue, that's expected, not a problem to fix.
4. 4When a granted scope is no longer needed, whether the operator's numbers have already appeared in the leaderboard or case study you asked for, or the initiative it supported has wrapped, withdraw the request from either board. That's the one action HQ takes to close the loop.

Related reading

• Consent requests: when a name or private figure can appear, where requests are authored: the Broadcast → Consent composer, the hero panel, and the full five-state lifecycle from the authoring side.
• Consent requests inside the decision log, a deeper walkthrough of the Decisions-board tile specifically.
• How the Action Plans timeline is built, the mechanics behind the Sent, Approved, and Closed checkpoints and how they're drawn for all four HQ sources.
• HQ Decisions: the franchisor inbox, the full board this row type lives inside.
• Action Plans: the network work in flight, the in-flight companion board.
• What HQ sees in Decisions and what it never sees, the privacy boundary across all four sources.
• The interventions queue for at-risk locations, the other source that names a specific operator.
• Item 19 basics, background on the disclosure rules some consent requests exist to satisfy.
• Broadcasting to your network, the outbound dispatch surface Consent is one tab of.

Data sources