Skip to main content

Activation checklist

Use this checklist before inviting real end users, enabling production integrations, or relying on Switera for live customer activity.

How to use the checklist​

  1. Open the app overview.
  2. Walk through each area below.
  3. Fix blockers before inviting real users.
  4. Leave only intentional follow-ups for after launch.
  5. Check audit logs at the end.
Switera app overview showing readiness and focus areas
Start from the app overview so the checklist matches the selected app.

App setup​

  • App name and slug are correct.
  • The app owner and operating team know which product this app represents.
  • The app overview does not show required setup blockers.
  • The correct app is selected in the sidebar before making service changes.
  • The app is not a duplicate of another app in the portfolio.

Organizations​

Switera organizations page with filters and create organization action
Organizations should be created and reviewed before customer access depends on them.
  • The first organization exists.
  • Organization name and slug are correct.
  • Invitations are sent only to intended recipients.
  • Organization roles are clear.
  • Domain auto-join is enabled only when the domain is owned and verified.
  • Groups and custom roles are used only when the app needs them.

Auth​

Switera sign-in methods settings
Confirm the first sign-in method and verification behavior.
Switera security settings
Review MFA, sessions, CAPTCHA, step-up, and privileged-session behavior.
  • At least one sign-in method is enabled.
  • Email verification policy matches the risk level of the app.
  • Password, passkey, magic link, social login, and SSO options are intentionally chosen.
  • MFA policy is configured for the audience you expect.
  • Session timeout and single-session behavior match your security requirements.
  • Legal URLs are correct if consent is required at sign-up.
  • Auth branding matches your product enough that end users trust the flow.

Email​

Switera email sender and brand preview
Confirm sender identity and visible email appearance.
Switera built-in emails catalog
Review built-in verification, recovery, welcome, and security messages.
  • Sender name and sender address are correct.
  • Sender domain DNS records are added and verified if custom sending is used.
  • Route test sends successfully reach a monitored mailbox.
  • Invitation templates and built-in messages are reviewed in every locale you use.
  • Suppression list is clean before launch.
  • Runtime delivery history does not show unresolved delivery issues.

Webhooks​

Switera webhook endpoint setup form
Webhook endpoints should be narrow, tested, and owned by a receiver team before production traffic starts.
  • At least one endpoint exists if your backend needs event delivery.
  • Endpoint URL uses HTTPS.
  • Subscribed event types are limited to what the receiver needs.
  • Endpoint signing secret is stored securely.
  • Test send succeeds and the receiver validates the payload.
  • Failed or pending deliveries are investigated before launch.

Developer credentials​

  • Test keys and live keys are stored separately.
  • Secret keys are used only from trusted backend services.
  • Publishable keys are treated as public identifiers.
  • Rotation steps are known before production traffic starts.
  • OAuth redirect URIs are exact and environment-specific.

Operations​

Switera audit logs page with filters and export actions
Use audit logs to confirm important setup changes and investigate anything unexpected.
  • Audit logs show expected configuration changes.
  • Export process is understood if compliance review is needed.
  • Team knows where to check user sessions, MFA status, webhook deliveries, email runtime, and audit history.
  • Troubleshooting paths are documented for sign-in, email, webhook, and API failures.

Launch decision​

Move to production use only when required setup is complete and the remaining items are intentional follow-ups rather than blockers.