Settings Module
The Settings module is the control center of RevenuePilot CRM. It is used to configure branding, security policies, OTP/TOTP limits, email/SMS channels, sessions, API clients, AI Bot integration, provider webhooks, and maintenance utilities. The goal is simple: admins can tune the CRM from UI without editing files.
Settings are grouped into clean sections (General, Branding, Security, OTP & TOTP, Channels, Sessions, API Clients, AI Bot, Provider Webhooks, Tools) and each section saves only what it is responsible for.
Internally, Settings follow a Repository + Repository Interface structure. The UI talks to services/repositories, keeping controllers thin and making the module easy to extend.
1) General
General settings control the basic identity and runtime defaults of your application. These values are used across the admin panel, emails, and system labels. Typical use cases include setting the application name shown in the header, setting the base URL used in links, choosing timezone for timestamps, and selecting date/time formatting for reports.
- Application Name: The full product name shown across the admin panel and emails.
- Short Name: A compact label used in smaller UI areas (sidebar/header labels) where space is limited.
- App Version: Display-only version shown in system info and help areas for support/debugging.
- Application Description: Optional description used in UI footers and/or email templates.
- App Type: Helps set defaults such as labels/prefixes (e.g. Invoice/Billing).
- App URL: Base URL used when generating links inside emails and notifications.
- Timezone: Impacts timestamps, audit logs, and OTP expiry calculations.
- Default Language: Sets the default UI language (where supported).
- Maintenance Mode: Can display a maintenance screen for non-admin users during upgrades.
- Date Format / Time Format: Controls how dates/times appear in tables, reports, and print views.
- Currency Code, Symbol, Position: Controls currency display (e.g., Rs before/after).
- Thousands separator & Decimal places: Controls number formatting across totals and reports.
8) API, Webhooks, And AI Bot
RevenuePilot CRM exposes API clients, outbound webhooks, provider webhook handling, and AI Bot sync controls from the settings/enterprise surfaces. Configure these only after roles, portal permissions, queue, scheduler, and System Health are stable.
- Create API clients for
/api/crm/v1access. - Document rate limits before sharing tokens.
- Register outbound webhook endpoints and retry behavior.
- Verify provider webhook signatures and replay controls.
- Enter AI Bot license/token before sync or webhook actions.
- Set webhook token and signature secret.
- Review auto-create lead, deal, and support ticket behavior.
- Keep operator actions approval-based for buyer safety.
2) Branding
Branding settings control your visual identity. You can upload logos and favicon, set primary/secondary colors, and choose light/dark styling. This is also where you enable login page branding so the login screen matches your product identity.
- Logo (Light): Used in light mode areas and inside email headers.
- Logo (Dark): Used for dark sidebar / dark mode header areas.
- Favicon: Browser tab icon (recommended square PNG/ICO).
- Default Avatar: Fallback profile picture for users without an avatar.
- Primary & Secondary color: Used for buttons, badges, highlights, accents and UI emphasis.
- Login Page Branding: Shows logo + app name on login for a professional first impression.
- Sidebar Theme: Changes sidebar appearance (light/dark/transparent).
- Layout Mode: Layout style such as fluid/boxed (if enabled in your build).
- App Mode: Switches the overall admin theme between light and dark.
3) Security
Security settings define how strict your password policy is and how the system reacts to suspicious login behavior. You can enforce MFA for privileged roles, require verified emails for access, and configure lockouts to protect accounts.
- Minimum password length: Sets the baseline password size (commonly 8-12).
- Password complexity mode: Choose basic/strong/custom complexity behaviors.
- Custom rules: Rules applied only when using custom complexity.
- Lock after failed attempts: How many consecutive wrong logins trigger a lock.
- Lock duration: How long the user must wait after being locked.
- Cooldown between attempts: Optional delay added to slow brute force tools.
- Password expiry: Forces password change after N days (optional).
- Prevent password reuse: Blocks reusing recent passwords (if enabled in your build).
- Allow login without verified email: Controls whether email verification is required before access.
- Security notes: Recommended safe defaults displayed for buyers.
4) OTP & TOTP Policy
This section controls OTP and TOTP behavior. The goal is to stop OTP spamming, reduce abuse, and keep login stable. Policies are expressed in plain terms (expiry, resend cooldown, rate window, maximum attempts and lock behavior) so buyers can tune without touching config files.
- OTP expiry (TTL): How long an OTP remains valid after generation.
- Max attempts: Wrong OTP entries allowed before a temporary lock.
- Resend cooldown: Minimum wait before requesting another OTP.
- Rate-limit window: Time window used to count OTP requests.
- Max OTPs in window: Hard cap for OTP sends inside the rate window.
- Locked TTL: How long the user stays locked after hitting limits.
- TOTP issuer: Display name shown inside authenticator apps.
- TOTP window: Small drift tolerance to avoid false failures.
- Email dispatch mode: Emails can be sent instantly (sync) or via queue. Sync sends immediately but may slow the UI because the request waits for delivery. Queue is recommended on VPS because a worker sends emails in background.
- Admin email notifications: When enabled, admin also receives email for major security events and OTP-related punishments.
- Channel toggles (Email/SMS/WhatsApp): Controls which OTP delivery methods are allowed. Keep at least one working channel enabled.
5) Channels (SMTP + Twilio)
Channels define how the application sends operational messages: OTPs, password resets, verification links, alerts, and system emails. Email uses SMTP. SMS/WhatsApp uses optional Twilio integration. You can test channels directly from the UI.
- Mailer: SMTP recommended; log useful for local testing.
- Encryption: Usually TLS.
- Timeout: Prevents hanging SMTP connections.
- Host & Port: Provider SMTP server address and port.
- Username & Password: SMTP authentication credentials.
- From email & From name: Default sender identity.
- Reply-to: Optional support email for replies.
- Send test email: Verify SMTP works before production.
- Twilio SID & Token: API credentials.
- Default country code: Helps normalize numbers.
- SMS From: Sender number for SMS.
-
WhatsApp From: Must include
whatsapp:prefix. - Enable SMS / Enable WhatsApp: Toggles for OTP delivery channels.
- Test buttons: Quick verification for SMS/WhatsApp routing.
6) Sessions
Session settings control how long users stay logged in and how cookies are handled. This is important for balancing security and convenience.
- Session lifetime: Minutes before session expires.
- Session driver: Where sessions are stored (database/redis).
- Encrypt session: Extra protection with small overhead.
- Expire on close: Ends session when browser closes.
- SameSite cookie: Cross-site cookie behavior (Lax recommended).
- Secure cookies (HTTPS): Enable in production.
- Logout other devices on login: Optional enforcement (if enabled in your build).
7) Tools
Tools provide maintenance utilities to keep the system healthy and make deployments smoother. These actions are commonly needed after updates, migrations, or when caches cause stale behavior.
- Clear cache: Fix stale config/runtime behavior.
- Rebuild config cache: Refresh cached config for consistency.
- Rebuild route cache: Faster routing in production.
- Clear views: Clears compiled Blade views after UI updates.
- Clear optimization cache: Clears other optimization caches.
- Rebuild storage link: Recreates public storage symlink.
- Seed essential data: Inserts required base data for the app.
All Settings in this module are applied at runtime
using
Laravel Service Providers. On each
request, the provider reads the latest values from
the database and
overrides the default application
configuration
(for example: app name, branding assets,
mail/notification channels, security rules, session
options, OTP/TOTP policy, etc.). This means buyers
can change behavior from the UI, and the changes
take effect across the system without editing
.env files or touching server-side
code.
Stored settings are treated as the source of truth. Provider-level logic ensures the saved values automatically replace defaults used by views, emails, and core runtime behavior.
The Settings module follows a Repository + Repository Interface structure (controllers stay thin, logic stays inside services/repositories), making the module easier to extend and maintain for future updates.