Skip to main content
Restricted Access: This documentation is only accessible to @tenzo.ai and @salv.ai email addresses.

​
Overview

A submittal share link is a revocable grant for one report (candidate, job, call). The link carries a random secret in the URL fragment (/shared/submittal-report#<secret>); Tenzo stores only its SHA-256 hash, so a link cannot be shown again after it is created. The shared page exchanges the secret for a 15-minute signed session and renews it before it runs out. Only the first exchange of a page load counts as an open in the recruiter’s link list; renewals update the link’s last use without adding an open. A renewal must present the page’s current, still-valid session for the same link, so a renewal cannot be claimed to hide an open, and a page that resumes after its session expired (a tab left hidden past 15 minutes) counts a new open. The page keeps the secret in memory only, so every page load, reload, or new tab (and the error state’s retry) is a new open. The customer-facing behavior is documented in Sharing a Submittal Report. Grants live in share_links, and every exchange is recorded in share_link_accesses. Both carry org_id and are removed with the org.

​
The feature flags

Both are per org in org_feature_flags. Allow up to 60 seconds per process for a change to take effect. Before turning the legacy flag off for an org, check that org’s legacy traffic in Datadog (below) and confirm the customer understands that links already sent in old emails, ATS notes, and exports stop working for anyone outside Tenzo. Independently of legacy_submittal_share_links, a report that has any submittal grant (active, expired, or revoked by a user) no longer opens through its own address without sign-in. A share session hands the recipient the report’s (candidate, job, call) ids, and the legacy path serves the report without the share projection, so leaving it open would let a recipient read the recording, dialing number, and internal notes, or keep reading after a revoke. Grants the system revoked because their email or export never went out do not count. Logged-out requests that carry that report’s (candidate, job, call) triple get the same 401 SHARING_LEGACY_LINK_DISABLED as the kill switch, so the page shows the same sign-in panel. Requests with a Bearer token fall through to session auth as usual, so staff are unaffected. This is per report and permanent: revoking or expiring the grants does not reopen its own address, and the report’s share links keep working. The check reads the primary database and is cached for 30 seconds per process (the issuing or revoking process drops its entry at once). The refusal is counted on auth.share_link.legacy_refused with reason:shared_by_link (the kill switch uses reason:org_disabled).

​
Revocation timing

Revoke and Revoke all take effect on the next request after the grant-state cache expires: up to 30 seconds per process, immediate on the process that handled the revoke. The customer page says “within a minute”. A valid session for a revoked grant is rejected with 401 SHARING_LINK_REVOKED, and the report’s own address stops opening without sign-in (see above). Revoking needs to be the issuer, or Manage Candidates on the job. System-issued grants (email, CSV) always need Manage Candidates.

​
Datadog signals

​
Which response a share viewer gets

Each legacy admission also writes a structured log line with the org, the three ids, the path, and whether a sign-in token was present.

​
Common questions

  • “The link says it expired or was revoked.” Check the report’s link list (open the report, click Share). Create a new link; an existing link cannot be extended or re-sent.
  • “The open count looks high.” Renewals do not add opens, but every page load does: reloads, new tabs, a tab resumed after its session expired, and the same recipient opening the link again on another day each count once.
  • “The report’s own address asks a client to sign in, but the flag is on.” Check the report’s link list: any share link, including CSV export links, closes the report’s own address. auth.share_link.legacy_refused with reason:shared_by_link confirms it. Send the client a share link.
  • “A recipient sees Out of scope.” A 403 SHARING_OUT_OF_SCOPE comes only from a declared route whose path names a different candidate, job, or call than the grant, or whose operation the grant does not include. A page feature calling a route that is not declared for share viewers fails with a plain 401 from normal auth instead; that usually means a new request on the report page needs an accepts_share declaration.
  • “After a signing key rotation, shared pages errored.” They should not: a session signed with a retired key answers SHARING_SESSION_EXPIRED, and the page re-exchanges its secret for a session under the current key.