#Signing In to the AiDial Portal

7 min read

#Overview

S-LP1 candidate source keeps password, required verification, recovery and activation on the Portal where sign-in began. M-AU23 has not yet released this candidate to both hosts; the instructions below describe the implemented candidate. Server-to-server native authentication and signed OIDC still precede DB-backed role/tenant/project access.

#How to Sign In

  1. Open your organisation's Portal and enter your email and password in the compact Sign in card. The password reveal button does not submit the form.
  2. Select Sign in. Complete only the step offered by the server. An eligible email code is selected first; check the masked destination and explicitly select Send code. No code is sent merely by opening or changing a method.
  3. Enter the received code and choose Verify, then Continue. Use another method lists only permitted usable alternatives, including authenticator apps, eligible SMS, existing recovery codes and keys. If the server requires no factor, Continue is available without inventing MFA proof.
  4. If first-time authenticator setup is required, explicitly start setup, add the private native manual key to a time-based authenticator and verify its code. Sign in again and complete genuine required verification before business access.
  5. A staged invitation requires explicit acceptance. Your invitation determines recipient, organisation and access; typing an email cannot create an account or choose a role.
  6. You return to the exact permitted page or pending account action. Without an explicit destination, existing role homes remain: Calls for client_staff, dashboard for other customer/partner roles, and the internal admin home for AiDial operations.

Use Forgot password? to explicitly request a reset email. The receipt does not reveal whether an account exists. Open the link in the same browser and explicitly confirm/save; opening a link alone does not verify, accept or sign in. Required password change uses the current password and then a fresh sign-in. Completed material credential changes invalidate earlier sessions through the native/API contract.

For a pending invitation, open More sign-in options to read the server-selected choices. Use an existing account or activate the invited account with your name and chosen password, verify the native email and complete required fresh authentication. Need a new activation link? requests a fresh modern link for an invitation/existing assigned account. Old InitUser links are not translated into modern codes. An account without a password may receive a separate password-setup link. Native7 release/live INITIAL proof remains a release gate.

If the link has expired, belongs to another browser or lost custody, start a new sign-in and explicitly request a new link. An uncertain result is never automatically retried.

#Passkeys and recovery

More sign-in options reads native primary-method availability. An offered passkey uses your browser authenticator. Only methods currently permitted by the server appear; unsupported browsers or cancelled ceremonies can use another allowed method. Existing auth-domain keys are not assumed portable. Keep a working method until a new key is tested; this flow removes no key. Account-security registration uses the Portal's native ceremony, fresh sign-in and confirmed readback before success.

Use an already-issued recovery code when offered by Use another method. If no supported method is usable, contact your administrator or help@aidial.com.au. Support does not replace an available reset, verification, activation or required setup path. Mandatory external federation remains blocked until its actual supported selection path is available; no hosted credential fallback is offered.

#How Sign-In Is Protected

Browser users sign in through the AiDial portal and should not send X-API-Key. API keys are for trusted direct server-side integrations.

The portal uses a Next.js App Router BFF model: the browser calls portal pages and same-origin route handlers under /api/**, and the portal server calls aidial_api with the bearer token from the signed NextAuth session. Shared server-side API transport strips inbound X-API-Key headers and injects the server-side bearer token.

Middleware covers non-API page routes. API route handlers under /api/** enforce their own authentication, role checks, CSRF protection where applicable, and tenant/project scoping.

Portal pages and actions check authentication, role permissions, and tenant/project scope. Navigation visibility is only a convenience and is not a security boundary. Out-of-role or out-of-scope routes are denied without revealing whether another tenant's resource exists.

#What You Can Access After Signing In

The portal sections available to you depend on your assigned role. See Roles & Permissions for a complete breakdown of what each role can access.

At a glance:

  • Dashboard, Calls, Support, Settings, and Notifications — Available to client and partner portal roles, with tenant/project scoping enforced server-side.
  • Account — The personal profile and security surface is available to client_admin, client_manager, and client_staff. For client_manager and client_staff, personal profile and active-session controls live only here rather than in Settings.
  • Status — Available to client, partner, and internal AiDial roles.
  • Billing — Available to client_admin, client_manager, and partner_admin only.
  • Compliance — Available to client_admin and client_manager, with administrator-only compliance subpages limited to client_admin.
  • Audit Log — Available to client_admin, client_manager, partner_admin, partner_user, aidial_admin, and aidial_operator.
  • Partner workspace — Clients, Projects, Outbound Campaigns, Partner Team, Analytics, Alerts, Knowledge Bases, and Telephony are available to partner_admin and partner_user. Team management lives in the partner workspace; there is no separate customer Team section.
  • Integrations and Capacity — Available to partner roles and internal AiDial roles where the route or panel permits that role.
  • Internal admin — aidial_admin and aidial_operator are redirected away from normal customer/partner portal routes and land in the internal admin surface, starting at the admin home (/admin). Current internal surfaces include Tenants, Users, Incidents, Discounts, Adjustments, Capacity, Integrations, Audit Log, Status, and Profile/remediation pages.

Some actions inside a section may also be limited by role, assigned scope, or route-specific checks. See Roles & Permissions for details.

#Common Access Issues

If you are unable to access the portal or see an "Access Denied" page, here are the most common reasons:

#Wrong Role

Your account role does not have permission to access the page you requested. For recognised roles that are out of scope for a route, the portal displays a generic "not found" page to protect the privacy of other areas. If the portal cannot recognise your role at all, it shows an access-denied state. Contact your organisation's administrator or AiDial support to verify your role assignment.

#Tenant Suspended

Your organisation's account has been suspended or is otherwise not active. Portal access is only available for active tenant accounts. Contact your AiDial account manager or AiDial support for assistance.

#MFA Required

Your role requires multi-factor authentication, but you have not yet enrolled or completed the current MFA challenge. Customer users are directed to Account > Security, partner users to Settings, and internal AiDial administrator/operator users are directed to Profile, to launch MFA setup or refresh security status before accessing protected pages. See Multi-Factor Authentication for enrolment steps.

MFA is mandatory for partner_admin, aidial_admin, and aidial_operator. It is optional but recommended for client_admin, client_manager, client_staff, and partner_user.

#Network Access Restricted

If your organisation restricts portal access to approved networks and your current network is not on that list, the portal signs you out and shows a "Network Access Restricted" page. Sign in again from an approved network, or ask your organisation administrator to update the tenant IP allowlist.

#Session Validation Unavailable

If the portal cannot resolve your session context during sign-in, it shows an access-denied state for session validation. Try signing in again shortly. If the issue persists, contact AiDial support.

#Unable to Sign In

If you cannot sign in at all:

  • Forgotten password — Use Forgot password? on the candidate Portal, open the new link in the same browser and explicitly save the new password.
  • Lost authenticator access — Use an already-issued recovery code or another allowed method offered by the candidate Portal. If no usable method remains, contact your organisation administrator or help@aidial.com.au.
  • Account locked — After too many failed sign-in attempts, your account may be temporarily locked by the identity provider. Wait a few minutes and try again, or contact your administrator.
  • Identity provider unavailable — In rare cases, the authentication service may be temporarily unavailable. Try again shortly. If the issue persists, contact AiDial support.
  • Stale browser session — If an old session cookie is no longer valid, the portal first shows a "Sign in again" page explaining that your secure portal access has expired. Choose Sign in again to return to the sign-in form; signing in again refreshes the session.

#Next Steps