User Registration

“Registration mode” controls how new user accounts come into existence. ActiveManage supports a spectrum from fully open self-service to fully controlled invitation-only, with several useful middle grounds.

Available Modes

• Open: Anyone can sign up using the public registration form. Captcha and email verification provide minimal friction. Best for consumer apps.
• Invite-only: Existing users (or admins) send an invitation link. Recipients click the link, set a password and they're in. Best for B2B SaaS, internal tools.
• Approval-required: Anyone can apply, but each application sits in a queue waiting for admin approval. Best for member-only communities.
• Domain-restricted: Registration is open but only to specified email domains (e.g. @yourcompany.com). Best for corporate intranets.
• Closed: No public registration at all; admins create every account. Best for high-security or back-office apps.

Switching Mode

Mode is set in Site Settings → Users → Registration. Switching is non-destructive — existing accounts are unaffected, only future signups follow the new rule.

Worked Examples

• SaaS launch: Open mode with email verification and a captcha for the first three months, then switch to approval-required once you're getting more signups than your support team can handle.
• B2B platform: Invite-only — every customer admin can invite their team members from inside the platform.
• Education platform: Domain-restricted to school domains, with parents on a separate invite-only flow.
• Members club: Approval-required — applications include profile details and admins review before approving.

Tip: Open mode without email verification is an invitation to bots. Always couple Open mode with verification and a captcha.

The welcome email is the first piece of brand-affirming, instruction-bearing contact your new user gets. A great welcome email reduces support tickets, boosts activation, and tone-sets the relationship.

What to Include

• Personalised greeting with the user's first name.
• A single clear CTA taking them to the most useful next step (verify email, set up profile, take a tour).
• 3–5 quick-start tips showing them the highest-value features.
• Where to get help — link to docs and a way to contact support.
• Reassurance — a line about privacy, security or a refund policy if relevant.

Configuring

1. Open Architect Panel → Email Templates and edit welcome_email.
2. Customise subject and body.
3. Test by triggering a self-registration in dev.
4. Enable by toggling Send welcome email on registration in Site Settings → Users → Registration.

Delivery Timing

• Immediate: Most common — sent on successful registration.
• After verification: Only send once they click the verification link, ensuring deliverability checking is real.
• Delayed (24 hour): Some apps stage a sequence — email 1 immediately, email 2 with tips the next day, email 3 with case studies a week later.

Worked Examples

• SaaS trial: Welcome → 2-day tip → 5-day case study → 12-day trial reminder. Each email drives toward a specific feature use.
• Consumer app: Single welcome email with “Download the app” CTA above the fold.
• B2B platform: Welcome includes per-tenant onboarding link the admin set up — “Your team's workspace is ready at tenant.yoursaas.com”.

Most modern apps use the email address as the username. It's familiar, memorable, and removes the “oh no I've forgotten my username too” support load. ActiveManage supports both, but defaults to email-as-username for external accounts.

Why Email as Username

• Less to remember: Users already know their email.
• Single contact channel: Password reset goes to the same place they used to sign up.
• Uniqueness for free: Email addresses are already unique per person.
• Familiar pattern: Almost every consumer app uses it.

When to Use a Separate Username

• Public profile platforms: Twitter-like sites where the username is your public handle.
• Privacy concerns: When sharing your username with strangers shouldn't reveal your email.
• Multiple accounts per email: Rare but possible — e.g. an admin who needs separate buyer and seller accounts on the same email.

Switching

If you switch from “separate username” to “email as username”, existing accounts keep both fields. Their email becomes their primary login but their old username still works for backwards compat. You can mark old usernames as deprecated after a grace period.

Worked Examples

• SaaS B2B: Email as username — minimum friction at signup.
• Forum platform: Separate username (the public handle) plus email for login and recovery.
• Marketplace: Email as login, with an optional “seller display name” for the public profile.
• Internal staff: Email as username, integrated with corporate SSO so the email is the IdP attribute.

When a new user registers, they need a security group — the group determines what they can see and do. Configuring sensible defaults means new users land in the right place automatically without admin intervention.

Default by Registration Source

• Public form: The default for self-service signups. Usually the lowest-privilege customer group.
• Invite from staff: Inherits whatever group the inviter selected on the invite form.
• Invite from admin: Defaults to a staff group; admin can override per-invite.
• SSO (Azure / Google / SAML): Mapped from a claim/attribute coming from the identity provider.
• API: Whatever the calling endpoint specifies — usually defaults to a “API-created customer” group.

Configuring

1. Open Site Settings → Users → Registration → Default groups.
2. For each source, pick the default group.
3. For SSO sources, define the attribute → group mapping table.
4. Optionally enable “Multiple group assignment” so users can belong to several groups out of the box.

Worked Examples

• SaaS marketplace: Public form → Buyer; invite from existing seller → Seller (same org); admin invite → Staff.
• B2B platform with admin/user split: Each tenant has its own “tenant_admin” and “tenant_user” groups. Default is tenant_user.
• Healthcare: Public registration disabled; clinicians come in via SSO mapped to “Clinician” group; patients come in via invite from clinic admin.
• Educational platform: Domain-restricted to school. Student domain → Student group; teacher domain → Teacher group.

Note: Always audit group assignments after a default-group change. Going from “staff” to “customer” as a default could leave the previous batch of registrants over-privileged if not migrated.