Subcontractor certs and the verification invite

What a subcontractor certification record is

Most of what sits in Certifications is paperwork you control directly: a technician's IICRC card, a firm-level license. A subcontractor certification is different. It is a credential, or a certificate of insurance, that belongs to someone outside your company, a sub you call in for mold, roofing, asbestos, or any scope you don't run with your own crew. You are relying on their paperwork, not yours, and until they hand you the actual document, all you have is their word for it.

That distinction, someone else's word versus their actual document, is what the verified flag on every subcontractor certification record exists to answer. This article covers that one flow end to end: how a sub cert record gets its verified/self-reported status, what happens when you click Send verification request, and what the sub sees on the other end of the link. For the full three-table data model behind Team, Firm, and Sub certs, see Team, firm, and subcontractor certifications. For the shape of the detail card itself, see Reading a certification's detail card.

Verinode does not chase the sub for paperwork or issue anything on their behalf. It reads what comes in, forwarded emails, uploaded photos, and the one-click link a sub fills out themselves, and turns that into a status you can act on. You decide when a cert needs chasing and who to keep on the roster; Verinode surfaces which subs are unverified or expiring so that decision doesn't get made by accident.

Where to find it

Open Certifications from the sidebar at iq.verinode.ai/certifications. Subcontractor cert records live in the same list as team and firm certs, tagged with the Sub Cert eyebrow label and a teal accent (the same Monitor-signal teal used across the platform), so they read apart from the green Team-cert and copper Firm-cert tiles at a glance. Open the All Certifications tile from the Explore row, or click any Sub Cert tile from Most Recent, to land on the record's detail card.

How a subcontractor cert record gets created

There is no "Add a subcontractor cert" form on the Certifications page today. The Add a credential panel under the page's cert-add flow only handles firm-scope credentials (an IICRC Firm designation, a state license) you hold yourself. Subcontractor records appear automatically, the same way team certs do: forward the sub's COI or certification email, or capture a photo of their cert card through Add Data, and the ingestion pipeline reads the document, identifies the sub as the holder (rather than a teammate or the firm), and writes a row to the sub's certification table with their name, the certification, the cert number if legible, and the expiry date.

Two things worth knowing about that path:

• A record created this way is not automatically verified. Even when the document itself came through email or a photo you uploaded, verified stays false on the row and the document is stored, but it's still the version you obtained, not the version the sub confirmed. Only a document the sub submits themselves through the verification link (below) flips the record to verified.
• Re-forwarding the same sub's renewal updates the existing row, it doesn't duplicate it. Ingestion matches on the sub's name plus the certification, so a renewed COI for the same sub and cert replaces the expiry, cert number, and document on the same record instead of creating a second entry.

Verified vs. self-reported

Every Sub Cert record's detail card shows a Verified field with two possible values:

• Verified document on file, shown in green when it also appears as a hero stat. The sub uploaded their certificate through the token link and Verinode is holding their document, not one you sourced yourself.
• Self-reported, the default for any record that hasn't been through the verification flow yet, regardless of how the record got its data, manual entry, an email you forwarded, a photo of a cert card, or nothing at all beyond a name and an expiry date you were told.

The same distinction shows up in two other places. The record's subtitle, right under the sub's name and cert on tiles and in Most Recent, reads "Verified" or "Self-reported" directly. And on the detail hero, one of the four stat tiles reads Verified: Yes (green) or Verified: No (neutral).

Why the distinction matters: a self-reported cert is exposure you're carrying without proof. If a carrier or an insurer ever audits a job this sub worked, "the sub told us they were certified" is a materially weaker position than a document on file with the sub's name on it. The verification flow closes that gap without you having to chase a PDF by hand.

The Sub Cert detail card

Opening a subcontractor cert record shows:

Hero stats (four tiles across the top):

• Expires: the certification's expiry date, colored to the stance (green when current, amber when a renewal window is open, red when exposed or expired), with a delta reading either "Nd left" or "Nd overdue."
• Verified: Yes or No, as above.
• Contact: the subcontractor's email if one is on file, otherwise their phone, otherwise a dash.
• Cert: the certification name, humanized from the stored slug (for example iicrc_wrt reads "IICRC WRT," never the raw underscore token).

Subcontractor Cert Overview, in the Details tab:

• Subcontractor: the sub's name.
• Certification: the humanized cert name.
• Cert Number: shown only when one was captured.
• Expires: the expiry date, formatted as "Mar 15, 2026."
• Verified: "Verified document on file" or "Self-reported," spelled out in full (not just Yes/No).
• Email / Phone: shown when present on the record.

Stance pill, next to the Sub Cert label in the eyebrow: Current, Expiring, Exposed, or Expired. For sub certs specifically:

• No expiry date logged at all reads Expiring with the label "No expiry set," and the action prompt is "Ask the sub for the current expiry date."
• Past the expiry date reads Expired, with the action prompt "Request updated cert from [sub name]." The consequence line differs depending on verification status: if the record was verified, it warns that an audit will catch the lapse; if it was never verified, it warns not to assume the sub renewed without proof.
• 30 days or fewer to expiry reads Exposed, with the action prompt "Send renewal request to [sub name]."
• 31 to 60 days out reads Expiring ("Renewal Due"), prompting you to queue the request rather than send it immediately.
• Beyond 60 days reads Current, with no action needed.

Below the overview sits the Verification panel, the control surface for the whole flow described next.

Sending the verification request

The Verification panel on a Sub Cert record has three states, depending on what's on file:

No email on file. The panel reads: "Add a sub email on this record to send a verification request." There's no button, add an email to the record first (directly, or by forwarding a document that carries one).

Email on file, not yet verified. The panel reads: "Send a one-click upload link so the sub can attach their cert. No account needed on their end." Below it, a Send verification request button.

Already verified. The panel reads: "✓ Document on file. The sub uploaded their cert via the verification link." Below it, a smaller Re-send verification link action, in case the sub needs to replace the document (a mid-term renewal, or a correction).

1. 1Click Send verification request (button reads "Sending…" while in flight).
2. 2Verinode looks up the record, confirms an invite token exists (minting a fresh one on the very first send) or reuses the existing token on a re-send, so the same link keeps working across multiple sends.
3. 3An email goes out to the subcontractor's address from Verinode, on the operator's behalf, with a subject line like "[Your company] needs a copy of your [CERT] certificate" and a single link to the public upload page.
4. 4On success, the panel confirms: "Sent, they'll get a one-click upload link by email." Re-sending an already-verified cert confirms instead: "Re-sent, they can replace the existing cert from the same link."
5. 5If the send fails (a bad address, a provider bounce), the token has still been minted and the request has been logged, only the email delivery itself failed silently server-side; the panel shows an error if the action call itself errors, otherwise nothing on your end changes.

The email the sub receives is written in plain language, no jargon: it names the company asking, states plainly which certification is on file for them, gives one link with no login required, and notes that uploading takes about a minute and closes the loop until the next renewal.

What the subcontractor sees

The link points to a public page, /sub-cert/verify?token=..., that needs no account and no password, the token in the URL is the only credential. It renders one of four states:

Invalid or missing token. "Link unavailable," with the specific reason ("No token provided" or "This link is invalid or expired"). This happens if the link is mistyped, or the underlying cert record no longer exists.

Already verified, replace option. If the sub (or someone) already completed the flow for this exact record, the page reads "Already verified," confirms the company already holds a verified copy on file, and offers a Replace cert form in case the document needs updating, "If you need to replace it, paste a new link below."

Fresh request, form to fill out. The page greets the sub by name, "Hi [Name], quick favor," states which certification the company has on file for them, and asks for a link to their certificate document, not a file upload. The sub pastes a URL, Google Drive, Dropbox, OneDrive, wherever they already keep the document, with a reminder to make sure the link is viewable by anyone who has it. One Submit button, no other fields.

Confirmation, after submitting. "Thank you, uploaded," with a note that the company will now see the cert as verified and the sub can close the tab.

The moment the sub submits, the record on your side flips verified to true and stores the document URL. There's no approval step on your end, the sub's submission is what verification means. Re-submitting through the same link (the Replace flow) simply overwrites the stored document URL and leaves verified at true, so a sub can update their document at renewal time using the exact same link you originally sent, no new request needed unless you choose to re-send for a clean confirmation email.

Peer Position

Every cert record, sub certs included, carries a Peer Position tab. When enough peer operators at your size and service mix have contributed data on this specific certification, it shows what share of them hold the same credential, framed qualitatively (for example, noting when a cert is a "table-stakes" hold among your peer set) rather than as a raw number you'd have to interpret yourself. Verinode never sells operator data to carriers, contributions like this exist purely to build the comparison other operators (including you) draw on. Until enough peer data exists for this specific cert, the tab reads: "Contributions unlock the comparison. Peer operators haven't yet shared enough data to benchmark this cert at your size."

Findings and Open Tips

Two tabs appear on the record only when there's something to show, and disappear otherwise: Open Tips, tactical nudges the tip detector has surfaced for this specific record, each with a headline, a short rationale, and a suggested next step; and Findings, any decision Verinode has linked to this cert, each showing the finding's title and, where relevant, a monthly dollar figure for the cost of leaving it unaddressed. Both carry a badge with their count and stay hidden entirely when there's nothing open, so an unverified-but-current sub cert with no linked findings shows neither tab, not empty ones.

Empty states you'll see

• No sub cert records yet, section-wide. The Certifications home page reads: "Capture your team's credentials" with three concrete first moves (upload cert PDFs, snap a photo of a cert card, forward IICRC renewal emails), none of which are sub-specific but all of which apply the same way once a sub's document comes through.
• Most recent tile row, empty. "Certifications will appear as you forward cert PDFs or capture credential photos."
• No email on this sub cert record. "Add a sub email on this record to send a verification request."
• No peer data for this cert yet. "Contributions unlock the comparison. Peer operators haven't yet shared enough data to benchmark this cert at your size."

Related reading

• Team, firm, and subcontractor certifications
• The certification detail card and stance engine
• How certifications land: uploads, photos, and email forwards
• The renewal radar: expiring and expired certs
• Certification benchmarks and peer position
• Forwarding documents into Verinode