A verification type can be marked as gating sign-in, blocking access to the application until it passes. It is powerful and easy to get wrong, so be deliberate.
What happens
At sign-in ActiveManage checks every enabled gating type. Any the user has not passed stops them proceeding until they do.
When it is right
- A regulated service where an unverified user must not see anything at all.
- An application whose entire purpose is available only to a verified population.
When it is the wrong tool
Gating is blunt. Where only part of your application needs verification — a discount, a restricted section, a particular action — check the user's status at that point instead. They can then get on with everything else while they sort their verification out, which is a far better experience and generates fewer support tickets.
Before you enable it
- Make sure you are not locking yourself out. A gating type pointing at a misconfigured provider can shut everybody out, including the people who would fix it. The Architect Panel is reachable independently — but do not rely on discovering that under pressure.
- Test the whole loop in sandbox: sign in, be gated, verify, sign in again.
- Think about rejections. A gating type that rejects a legitimate user with re-verification off leaves them no route back.
- Think about expiry. A gating type with 365-day validity will, a year later, begin turning your existing customers away at the door. That may be exactly what you want — make sure it is.
Worked Examples
- Regulated trading platform: gating is appropriate — nobody unverified should see anything.
- Retail site with student pricing: gating would be a serious mistake; check at the basket instead.
- Staff-only portal: gate on an organisation check rather than relying on the login source alone.