Verinode
Open Verinode

The access trail: who pulled what, when

The **access trail** is a running log at the bottom of the Vault page. Every time someone generates or opens a compliance document through HQ, a row lands here recording who pulled it, what it was,…

6 min read·Updated July 14, 2026
On this page

What it is

The access trail is a running log at the bottom of the Vault page. Every time someone generates or opens a compliance document through HQ, a row lands here recording who pulled it, what it was, and when. It exists so a franchisor can answer "who has seen this?" during a compliance review, a Discovery Day, or an FDD (Franchise Disclosure Document) filing, without reconstructing the answer from memory or email threads.

It is a record of document activity only. It never shows an individual franchisee's private business data, and it never crosses into a single membership's own numbers. HQ works with aggregates and compliance artifacts, and the access trail is no exception: it logs which network-level document was pulled, not what any one franchisee reported.

Where to find it

Go to Vault in the HQ sidebar (hq.verinode.ai/vault). The page opens on the document library: your generated reports organized into tiles by type (Discovery Day Packs, quarterly reviews, compliance audits, member cohorts), with a Generate report → button in the top right for admins that routes to the Discovery Day builder where new packs are actually created. The Vault page itself is a library and index, not a generator.

Scroll down. Below the library, under the heading Access trail, you'll find the log. It sits directly on the page with a hairline divider between rows, the same as every other list on the platform. There is no separate page or tab for it, and nothing to configure.

What each row shows

Each row has three parts, read left to right:

  • Document kind, followed by who pulled it. The document kind is one of:

- Item 19 pack, a Financial Performance Representation pack built for a specific franchisee cohort, meant to be cleared by counsel before it's dropped into an FDD. - Discovery Day pack, the report bundle generated for prospective-franchisee discovery days. - Recruitment deck, a deck built for recruitment conversations. - Board slide, a single slide generated for a board or leadership update. - Counsel-review link (signed), covered in its own section below. - Anything outside that list shows up with a plain, readable label instead of a raw code.

The name after the puller shows one of three things: a real teammate name for a signed-in admin pull, Outside counsel for a signed counsel-review link, or a plain Group user fallback in the rare case a name can't be resolved.

  • Context line, in smaller muted text underneath. This shows whatever detail applies to that specific pull, for example a section name, a shortened cohort reference, a fiscal year and quarter, a franchisee count, or a methodology-version tag. Not every document kind carries all of these; the line only shows what's relevant, separated by dots. If nothing applies, it shows a plain dash.
  • Timestamp, right-aligned, showing the full date and time the pull happened (for example, "Jul 14, 2026, 3:45 PM").

Rows are sorted most recent first. The trail shows the 30 most recent pulls across your network.

How the puller's name is shown

Most rows are attributed to a real person: an HQ team member who was signed in when they generated or opened a document. In that case, the trail shows their real first and last name, the same as it would appear anywhere else in HQ.

Note

On a shared preview or trial network, teammate names in the access trail show as "A teammate" instead of a real name, unless you're signed in as the network's designated Account Owner, in which case you see full names as normal. This keeps a shared demo account from exposing one tester's activity to another. On every live franchise network, every viewer with Vault access sees full real names.

The counsel-review case

An Item 19 pack usually needs sign-off from outside counsel before it goes into an FDD. HQ supports that without requiring counsel to have a login. When an admin submits a cohort for counsel review, HQ generates a signed link with an expiration date (14 days by default, adjustable up to 60), and emails it to the reviewing attorney.

When counsel opens that link, the underlying pack is generated the same way as any other Item 19 pack, but the pull is authorized by the signed link itself rather than a signed-in HQ session. That access still gets logged. The row records it as Counsel-review link (signed) and attributes it to Outside counsel rather than a named HQ team member, because there's no HQ session behind that pull. Everything else about the row, including the cohort reference and the exact timestamp, is recorded the same way as any other pull.

This matters for the trail's usefulness as a record: it shows not just that your team generated the pack, but that counsel actually opened it, and when, independent of any email confirmation.

If the link has expired by the time counsel clicks it, they'll see a message asking the HQ admin to resubmit the cohort for review, which mints a fresh link. No pull is logged for an expired or invalid link, since it was never actually authorized.

Empty state

If no documents have been pulled yet, the section reads:

"No document pulls recorded yet. The first download from any HQ document route lands here."

This is expected on a brand-new network before anyone has generated a report. As soon as anyone opens their first document, the first row appears.

How to use it

  1. 1Open Vault from the HQ sidebar.
  2. 2Scroll to Access trail, below the document tiles.
  3. 3Scan for the document kind you're checking on, for example confirming which teammate pulled the latest Item 19 pack, or verifying that a counsel-review link was actually opened before a filing deadline.
  4. 4Use the context line (section, cohort, fiscal period) to match a specific pull to a specific report if your network has generated more than one of the same kind recently.
  5. 5Treat this as a rolling window on recent activity, not a long-term archive. If you need a record beyond the 30 most recent pulls, note it down before it ages out of the list.

Tip

If you're preparing for an FDD filing or a compliance review, check the access trail a day or two ahead of time rather than at the last minute. That gives you room to notice anything that looks off, like a missing counsel pull or an unexpected gap, while there's still time to sort it out.

Note

For Discovery Day packs specifically, this trail is the record. Pulling a pack from the Discovery Day builder downloads the PDF to your browser and lands a Discovery Day pack row here, it does not also file a copy into Vault's Discovery Day Packs library row. So if that row still reads "No Discovery Day Packs generated yet" after your team has shared several packs, that's expected today, not an error, and this trail (or the Discovery Day page's own Pack history per prospect panel) is where to confirm what went out and when. See Discovery Day Packs in Vault.

Why the log write is non-fatal

Recording a row happens as a side effect of generating or opening a document, not as a precondition for it. If the log write itself fails for any reason, that failure is caught on Verinode's side, but it never blocks or delays the document someone actually asked for. You get your pack either way.

The trade-off is transparent: the access trail is a best-effort compliance record layered on top of the document flow, not a hard gate in front of it. It's there to help you demonstrate access discipline, not to enforce it by blocking downloads.

Related reading

Data sources

  1. 1.Verinode HQ product documentation. Verinode.
Was this helpful?