# Initial company administrator access

Company creation uses the selected plan's price, billing currency, trial duration and limits. A billing frequency is requested only when the plan has multiple priced frequencies. Start and renewal dates are calculated automatically in the company timezone. **Custom subscription (optional)** enables negotiated prices, dates and limits. Existing agreements and legacy API inputs are preserved; old saved drafts retain their custom values.

With **Email activation invitation**, creation saves the company first, then immediately attempts submission through the saved Platform email connection (SMTP or supported API provider). It does not wait for a queue worker or maintenance cron for the first attempt. The delivery record remains for audit, deduplication and failed-send retries. A successful submission means the email provider accepted the message; spam filtering and final inbox delivery remain with the provider.

If Platform email is disabled or submission fails, the company remains saved with activation pending and the page displays a clear warning. Configure Platform email and click **Send activation email**, or open **Set password instead** on Company → Administrators. No invitation confirmation checkbox or repeated password-confirmation page is required for these actions.

The manual password fallback is restricted to Super Admin and an initial pending company account. It validates the password and confirmation, activates the account, invalidates previous invitation links and sessions, cancels pending invitation deliveries, and records the action in the audit log. It does not mark an unverified email address as verified. It cannot reset an existing activated or unrelated company's account.

Password meters are provided on initial administrator creation, manual activation, email activation and password reset. The server still enforces the configured password rules. MFA remains optional. No plaintext passwords are emailed or stored in drafts, delivery records or audit metadata.

No migration or new always-running service is required. Deploy the committed source and compiled assets, then clear cached configuration, routes and views using the existing deployment commands. Existing cron maintenance continues to retry failed messages and handle other scheduled notifications.