Team
Adding colleagues, deciding what each one reaches, and setting how the review queue is worked
Team is the roster of your organization, and it is also where the rules for how your reviewers work are set. It is owner territory, with parts of it delegated to a review manager.
Adding somebody
There is no self-serve sign-up, so you create the account yourself.
Add them. Their name, their email, and the role they should start in. You confirm with a code from your authenticator app, because creating an account for somebody is a sensitive act.
They receive an invitation. It carries a link for setting their own password, works once, and expires 30 minutes after it is sent. Their page shows the email leaving, and whether it bounced.
They finish setting up. They set a password and enrol an authenticator app on first sign-in. Neither step is skippable.
Two variations are worth knowing. If nothing could be queued to send, their seat still exists and shows on the roster, but no email is coming: open their page and resend the invitation, or send them to the sign-in page to use the forgotten-password link. And if the address is already registered with TrustWix, they are added to your team without their password being touched, so they sign in with the one they already have.
The roster
Each row is a member with their role, status, environments, flow access and permissions. Status is active, invited, or disabled.
Three things decide what somebody reaches, and all three are edited from their member page.
| Control | What it decides |
|---|---|
| Role | The preset of what they can do. See Roles |
| Environments | Sandbox only, live only, or both. The only thing gating real applicant data |
| Flows | Which of your businesses they work on. Narrowing hides every verification, person and review outside those flows |
Changing a role clears the individual permissions that person had, because the new role brings its own. Selecting no flows at all means they see nothing at all, and the console warns you as you do it. Each of these changes asks for your authenticator code, since each can hand somebody applicant details.
A member's page
Access holds the role, the individual permissions grouped by console section, the environments and the flows. Every permission carries a one-line explanation of what it actually lets somebody do. You cannot grant a permission you do not hold yourself, and a handful of the most consequential ones can only be handed out by an owner.
Your user id for them connects this seat to your own systems. Fill it in with whatever you call this person internally, and your back office can then act as them: their decisions are recorded under their name, their permissions here are the permissions they get there, and suspending them here cuts off both at once. Leave it empty and the seat works only in this console. Only an owner can set it, and changing it asks for your authenticator code, because it grants a new way to become somebody.
You only need this for people who will decide cases from your own systems. Reading verifications into your own database needs no seats at all, just an API key.
Workload is what they are carrying in the review queue right now.
Seat is where you suspend or reinstate them. Suspending signs them out, stops them signing back in, and returns their open cases to the pool. Their history stays, which is the difference between suspending and removing.
Email lists every message we owed this person, newest first. Sent means a mail provider accepted it; delivered means the receiving server took it, which arrives a little later. If an address has hard bounced or been reported as spam we stop writing to it entirely, and the page says so: nothing reaches them until the address is cleared, whatever you send.
Activity is what this person has done in your organization. Applicant details are never shown here, whatever the event touched.
Review policy
This block decides how the queue is worked, and it is the setting most worth getting right early.
Queue visibility is whether every reviewer sees every case, or only their own. Owners and review managers always see everything.
Automatic assignment either leaves new cases in the unassigned pool until somebody hands them out, or sends each one to whoever has the fewest open cases. The automatic option prefers reviewers who are online, and never sends anybody a case from an environment they cannot open.
Claiming decides whether a case has to be taken from the queue before it can be decided. With it on, two reviewers never work the same applicant. With it off, they can, and can reach opposite conclusions. A claim lasts sets how long somebody holds a case before it returns to the queue for somebody else.
Automatic decisions settle cases from the score. You set an approve-at-or-above threshold, a reject-at-or-below threshold, or one of the two, as whole percentages of the overall verification score. Everything between them still goes to your reviewers.
Automatic decisions are real decisions
Applicants are emailed and your webhooks fire, exactly as if a person had decided. A case with any failed check is never approved automatically, and the feature is off unless you switch it on.
Trial run applies your thresholds once, to your oldest waiting cases, without turning automatic decisions on. It reports how many it approved and rejected. Those decisions are also real, so treat the trial as a controlled release rather than a preview.