InsureERP

Online and portals

SMS, languages, 2FA and SSO

Three quieter pieces of version 3: text messages, languages, and tighter sign-in.

SMS and WhatsApp

Set the driver under Settings > Company settings > SMS and WhatsApp:

  • Log only (the default) - messages land in the SMS log and nothing is really sent. Safe for trying everything.
  • Twilio - your own SID, token and sender numbers; WhatsApp works through a WhatsApp-enabled Twilio number.
  • Any HTTP gateway - a URL that accepts a POST with to, message, channel and from; most local SMS providers have one.

What goes out by text: payment links, payment receipts, overdue reminders, claim registrations and renewal reminders - for customers whose Reach me by is SMS or WhatsApp (set on the customer, or by the customer themselves on the portal). The wording is yours: Settings > SMS templates. Every message, sent or failed, is in Settings > SMS log.

Languages

Customers choose English, Arabic or French for the customer portal (under My details); Arabic runs fully right-to-left. The public membership card, payment and signing pages follow the company's language settings; your email and SMS templates are free text, so write them in whatever language your customers read. The staff screens stay in English.

Two-step sign-in (2FA)

Every panel - staff, platform, and all three portals - offers two-step sign-in with an authenticator app (Google Authenticator, Microsoft Authenticator, 1Password...). Each person switches it on from their own profile menu; recovery codes are shown once at set-up. Nothing to configure company-wide.

Single sign-on (SSO)

Staff can sign in with your company accounts instead of passwords - Microsoft Entra ID, Google Workspace, Okta, Keycloak, or anything OpenID Connect:

  1. Register an app with your identity provider, with the redirect URI shown under Settings > Company settings > Sign-in and SSO.
  2. Paste the issuer URL, client ID and client secret there.
  3. Share your sign-in link - /sso/your-company - with your staff.

SSO replaces the password, not the account: a person must already exist under Users with the same email. Tokens are verified cryptographically against the provider's published keys; every SSO sign-in is in the audit trail.

Did not find what you need? Send us a message.