Consent requests inside the decision log

What this page covers

A consent request is HQ's own ask of one franchisee: permission to name them on a leaderboard, show a metric for them in a specific view, feature their numbers in a case study, or open job-level detail. You author that ask from Broadcast → Consent, covered in full in Consent requests: when a name or private figure can appear. This article is about the other place the same request lives: as a row on the Decisions board, alongside your decision plans, interventions, and program audits.

Decisions is the shared inbox described in HQ Decisions: the franchisor inbox. This article is the deep dive on one of its four sources: the moment you send a request, it stops being only a Broadcast composer entry and becomes a tracked row here too, so leadership can see, at a glance and without opening Broadcast, which asks are still waiting on a franchisee and which have already been answered.

Where to find it

Click Decisions in the HQ sidebar. The page lives at hq.verinode.ai/decisions. The header reads Decisions, and the subtitle underneath it reads: "Network-level decisions across plans, interventions, consent requests, and program audits, the franchisor inbox." Consent requests are one of the four streams that feed this single gallery; they're not a separate tab or a separate page inside Decisions.

How a request gets here

The row is a live read of the network data, the same table Broadcast → Consent writes to. There's nothing to configure and no separate step to publish a request into Decisions: the instant you click Send request on the Broadcast composer, that record exists, and it appears on the Decisions board the next time the page loads. The reverse holds too: withdrawing a request from either surface updates the same row everywhere it appears.

Decisions doesn't pull every consent request your group has ever sent. It reads every request still pending, no matter how old, plus any request of any status that changed in roughly the last three months. A request that was approved, declined, or withdrawn longer ago than that has aged off this particular board. It still exists (Broadcast → Consent's "Recently resolved" row and its "All-time" counter keep the full history), it's just no longer part of the active inbox Decisions shows you.

The five statuses, and what they look like on this board

Consent requests carry their own five-state lifecycle underneath, but Decisions projects every source into one shared set of tile statuses so the board reads consistently no matter which of the four sources a row came from. Here is exactly how each consent-request status lands:

| Request status | Tile status shown | What it means | |---|---|---| | Pending | Pending | Sent, waiting on the franchisee. Nothing is disclosed yet. | | Approved | Acted | The franchisee said yes. The scoped disclosure (the named leaderboard slot, the named view, the case study, the deep-data access) is live. | | Declined | Ignored | The franchisee said no. Nothing is disclosed. HQ can send a new, differently scoped request later, but this one is closed. | | Withdrawn | Ignored | Either HQ or the franchisee pulled it back. Whatever was disclosed under it (if it had been approved) stopped the moment it was withdrawn. | | Expired | Parked | The auto-expire window passed with no response. Functionally the same as declined, no disclosure, but the tile reads Parked rather than Ignored because that's the shared bucket an unresolved timeout falls into. |

That last row is worth remembering on its own: if you're scanning the board for expired requests, they don't carry a label that says "Expired." Look under Parked.

Declined, withdrawn, and expired requests never reach the shared "Resolved" status other sources use (a completed decision plan, for instance, does land there). A closed consent request always shows as Ignored or Parked, never Resolved.

Reading a tile

Each consent-request tile shows:

• A domain glyph in place of an entity logo. Franchisees don't carry a logo the way vendors, clients, carriers, or TPAs do, so the icon is the domain watermark instead.
• The title, your rationale text, the same free-text explanation you wrote when you sent the request. If a request somehow has no rationale on file, the title falls back to the plain label "Consent request."
• The entity name, the franchisee the request is about. Per the privacy boundary described below, this is anonymized by default.
• A colored status pill: amber "Pending," green "Acted," teal "Parked," or grey "Ignored," matching the table above. The tile's top accent bar carries the same color.
• A date, when the request was first sent.

Consent-request tiles never show a dollar-impact figure. HQ doesn't calculate one for this source, so the field that carries a number on other tiles is simply absent here.

Business area and severity

Every row on the Decisions board carries a business-area domain, and consent requests always carry Governance. It's a fixed tag for this source, not something that varies by request kind or franchisee. Once your board has rows spanning two or more business areas, an area dropdown labeled "All areas" appears above the gallery; picking Governance narrows the list to consent requests only (plus anything else tagged Governance, which today is nothing else). The dropdown's count updates live and reflects whatever status filter is already active, so filtering to Pending and then Governance tells you exactly how many requests are still waiting on a franchisee.

Severity is fixed too: every consent request is Info, Verinode's lowest severity tier. A request awaiting a response is a normal, expected part of running the network, not a flagged problem, so it never carries Warning or Critical shading the way a disputed audit or an escalated violation can.

Controls on the tile

This is the one place the read-only framing matters most. HQ authored the request, but HQ doesn't get to decide its outcome:

• 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 franchisee, an approved one immediately revokes whatever was disclosed under it.
• Act and Not now never appear on a consent-request tile, in any status. Approving or declining is the franchisee's call, made from their own IQ deck, not something HQ can do from here.
• Once a request reaches Ignored (declined or withdrawn) or Parked (expired), there is nothing left to do with it from this board. There's no Ignore button on a request that's already closed.

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

Inside the slider

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

• The rationale as the header title, same text as the tile.
• A Metrics line listing the specific metric keys the request covers, when any were attached.
• The franchisee 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 doesn't carry a separate resolved date on this view. Since expiring is a passive timeout rather than an action anyone took, the only date recorded is the original send date.

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

The privacy boundary

A consent request always names a specific franchisee, which is exactly the kind of disclosure the platform normally protects. Unless your network's entity model is set to a single legal entity (one operator running every location), the franchisee's real location name is replaced with a stable anonymized label everywhere it would otherwise appear on this board: on the tile, in search results, and inside the workspace slider. This is the same anonymization Interventions rows use, and it's on by default for every multi-franchisee network.

This board itself never reaches into a franchisee's own business systems to build a consent-request row. Everything behind it, the rationale, the metric list, the status, the timestamps, comes from the network data, a table your own HQ admins write to when they send a request. Approving or declining a request is the one moment a franchisee's own answer flows back in, and even then, what actually gets disclosed is scoped to exactly the metrics, kind, and time window the request named, never anything broader.

Empty states

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

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

There's no separate empty-state message specific to Governance or to consent requests. Filtering to Governance with nothing pending, for instance, shows the same generic "Nothing pending for you right now" line the rest of the board uses.

Best-practice example

Say you sent three "Named on a leaderboard" requests last week for your Q3 top performers. Open Decisions, filter status to Pending, then filter area to Governance. Two tiles show up: the third franchisee already approved, so their request moved to the "Acted" bucket and dropped out of Pending. For the two still showing, check the date on each tile, if one has been sitting for several days with no response, that's your cue to follow up directly rather than wait on the auto-expire window to run out and quietly flip it to Parked.

Related reading

• HQ Decisions: the franchisor inbox, the full board this row type lives inside: search, filters, the other three sources, and the shared privacy boundary.
• Consent requests: when a name or private figure can appear, where requests are authored, the hero panel, the five-state lifecycle in full, and what the franchisee sees on their side.
• The interventions queue for at-risk locations, the other Decisions source that names a specific franchisee.
• Broadcasting to your network, the outbound dispatch surface Consent is one tab of.
• HQ benchmarks, where named leaderboard placement and named views actually render once a request is approved.
• Item 19 basics, background on the disclosure rules some consent requests exist to satisfy.
• What HQ sees, the platform shell this page lives inside.

Data sources