How operators request member verification

What this is

Every row that lands in your Verification Queue started on the other side of the platform, in an operator's own Verinode IQ account, not in HQ. This article walks through that operator-side moment: what an operator sees and does in their own settings when they tell Verinode they belong to your association, and exactly how that single action turns into the four states you'll see a claim move through: none, pending, verified, and rejected.

Nothing an operator does here activates anything. Self-declaring only ever writes a pending request. Your association is always the one that turns a request into an active membership, by approving it against your own roster in the Verification Queue. This article is the "before" half of that story; Working the verification queue covers the "after" half, where your team reviews and decides.

Where operators do this

Operators self-declare from their own account, under Settings, not from anywhere inside HQ. It's a single control: a toggle labeled

I am a member of the Restoration Industry Association (RIA)

with the description underneath it:

Self-declared. RIA confirms your membership against its roster before your RIA badge and RIA network benchmarks turn on. We never share your business data with RIA.

That last sentence is worth sitting with, because it's the whole privacy posture in one line. Turning the toggle on tells Verinode "check me against the roster." It does not hand your association any of that operator's business data. Your association only ever gets to see what the reconciliation produces: a proposed match in your queue, and later, if you approve it, that the operator is now a verified member. Their financials, jobs, and day-to-day account stay exactly where they've always been, on their side of the boundary.

Declaring: what the operator does

1. 1The operator switches the toggle on. This alone submits a self-declared request; no roster lookup happens synchronously, and nothing on your side gets a badge or benchmark access yet.
2. 2A second field appears, RIA Member Number, with the helper text "Optional, but it speeds up verification." The operator can type the number they believe your roster has on file for them (placeholder example shown in the field: "e.g. 100482") and click Save.
3. 3The member number is optional. An operator can leave it blank and still have a pending request sitting in your queue; it just won't have a member-number candidate to offer until either they add one later or your roster happens to carry a matching email address instead.

The four states, and what each one means for you

Every operator's relationship to your association sits in exactly one of four states at any time. This is also the exact language the operator sees on their own settings screen, since Verinode shows them a status line that mirrors it.

| State | What triggered it | What the operator sees | What you see | |---|---|---|---| | None | The operator has never turned the toggle on, or previously withdrew | No status line at all; just the toggle, off | Nothing. This operator has no row anywhere in Member Directory. | | Pending | The operator just turned the toggle on (or already had it on) | "Pending verification by RIA. Your RIA badge and RIA network benchmarks activate once RIA confirms your membership." | If the declared member number or email matches a roster row you've imported, it's a candidate waiting in your Verification Queue. If nothing matches yet, it's still pending, just with nothing to review until your roster catches up. | | Verified | An admin on your side approved the request against a roster row | Either "Verified RIA member. Your RIA badge and RIA network benchmarks are active." (dues current), or "Your RIA membership is on hold. RIA shows your dues as not current, so the badge and RIA benchmarks are paused until renewal." (dues lapsed) | The operator shows "On Verinode" on their roster row, and their membership counts toward your On Platform stat. | | Rejected | An admin on your side rejected the request | "RIA could not match your membership. Check your member number below, or reach out to RIA." | The request no longer appears in your Verification Queue. Nothing else on your roster changes. |

Why a request can sit pending with nothing in your queue

An operator's request only becomes a visible candidate in your Verification Queue once it lines up with a row on your imported roster, by an exact match on member number or on the email address tied to their Verinode account. Until then, the request is real and sitting in a pending state, but there's nothing for your team to act on yet.

This is normal and expected in a few situations:

• Your association hasn't imported a roster yet, or hasn't imported this operator's row.
• The operator's declared member number has a typo, or doesn't match how it's recorded on your roster (a stray space or a formatting difference is normalized away automatically, but a genuinely different number will not match).
• The operator left the member number blank and their account email doesn't match the contact email on file for them on your roster.

None of these require you to do anything specific for that one operator. As soon as your roster carries a row that matches what they declared, whether because you import it for the first time or correct it in a later import, the request surfaces as a candidate in your queue on its own.

Updating a declared member number

An operator can come back to Settings at any time while their request is pending (or even after it's verified) and change the member number in that same field, then click Save. This only ever refreshes the number and the account email attached to the request; it does not touch or downgrade the status. A verified member who edits their member number stays verified. This matters because it means editing the field can never accidentally undo an approval your team already made.

Withdrawing

If an operator turns the toggle back off, their request is withdrawn entirely and their state returns to none. If they had reached verified status, withdrawing also turns off their badge and pulls them out of your association's benchmark cohort immediately; there is no separate "leave the roster" step on your side to clean up after them. Withdrawing removes the request outright rather than leaving a rejected trace behind, so if that operator later declares membership again, it starts as a brand-new pending request.

What this means for your side of the workflow

Nothing here requires action from your association until a request surfaces as a candidate in your Verification Queue, and even then, approving or rejecting is always your team's call, never automatic. The two things worth keeping current on your end so requests resolve quickly are the ones the rest of Member Directory is built around: an up-to-date roster (so member numbers and emails have something to match against) and current dues statuses (so an approved match doesn't sit paused as "on hold"). Both are covered in Member Directory: the reconciled membership model and Importing your association roster.

Empty states, verbatim

• An operator with no pending or verified request: no status line shows at all under the toggle; the toggle simply reads off.
• Your Verification Queue with nothing to review: "No members are waiting for verification. New requests appear here as operators declare membership."

Related help

• Member Directory: the reconciled membership model
• Working the verification queue: approving members
• Importing your association roster
• What HQ sees: the network privacy boundary