Waqar Ul Wahab
ALL PROJECTS/AMALAXIS PORTAL

Overview

AmalAxis Portal is the company operating system AmalAxis built to run its own business end to end. A single Django backend serves two audiences at once: an internal workforce — staff, team leads, HR and the GM/CEO — and external customers who log in through a dedicated client portal. It replaces the usual sprawl of spreadsheets, chat apps, trackers and one-off document tools with one authenticated, permissioned surface.

Walkthrough

A short product walkthrough of AmalAxis Portal.

Problem

Growing service businesses tend to run on a patchwork: one tool for tasks, another for chat, a spreadsheet for leave, an inbox for client reports, a shared drive for invoices. The seams are where work leaks — context is lost between apps, permissions are inconsistent, and nobody has a single source of truth. The brief here was to collapse that patchwork into one system that could hold task management, HR records, attendance and leave, a CRM with booking, a design-asset library, a marketing planner, an infrastructure vault, and a full client-facing billing and report workflow — while keeping employee data and each client's data strictly isolated behind a coherent role model. It had to run in real time (chat, notifications, presence), stay resilient when a dependency like Redis blips, and expose everything through a clean versioned API for a separate single-page front end.

System Design

How It Works

01/04
01

AI assistant action execution

The in-portal assistant turns a natural-language request into permission-checked, auditable portal actions instead of free text.

  1. 1A staff user asks the assistant to do something, e.g. create and assign tasks or approve a leave
  2. 2A context builder assembles the relevant org state and sends it to OpenRouter with the available-action schema
  3. 3The model replies with natural language plus structured action blocks (create_task, create_project, approve_leave, create_announcement, ...)
  4. 4The ActionExecutor re-checks the user's RBAC permissions and requires a confirmation token for destructive, org-wide actions
  5. 5Executed actions write real rows and fan out notifications, keeping the assistant's output auditable
02

Website chatbot lead capture

A public multilingual chatbot answers visitor questions and quietly promotes qualified conversations into CRM leads.

  1. 1A visitor messages the public, unauthenticated chat endpoint, which is rate-limited per IP
  2. 2The bot answers from a bundled knowledge base and auto-detects the language (English, Urdu or Roman Urdu)
  3. 3Across turns it asks for name, then email or phone, extracting those fields from each reply
  4. 4Once name plus an email or phone is captured, the backend mirrors the visitor into a CRM Lead with source_type='website'
  5. 5Staff triage the conversation and lead from a Website Chats inbox in the portal
03

Client report and billing delivery

Staff produce reports and billing documents that clients receive, review and sign inside their own scoped portal.

  1. 1Staff draft a report, invoice, estimate or proposal in the client-portal subsystem
  2. 2On publish, the document is rendered to PDF and stored on DigitalOcean Spaces (S3)
  3. 3The client sees it in their scoped portal and a Resend email is sent, subject to the email-freeze whitelist
  4. 4Clients review and sign, with payments recorded against the document; e-sign packets download as the original plus a certificate of completion
  5. 5Renewals and certification expiries are tracked, with scheduled alerts dispatched on a schedule
04

Real-time collaboration

Chat, notifications and presence update instantly over JWT-authenticated WebSockets backed by Redis.

  1. 1An event (chat message, task change, notification) first writes a persistent database row
  2. 2The relevant app calls group_send on the Redis-backed Channels layer
  3. 3Daphne pushes the update over a JWT-authenticated, origin-validated WebSocket to every connected tab of the target users
  4. 4In-app bell notifications and presence update instantly, while the email copy is gated separately by the freeze whitelist

Key Features

  • Twenty-one-module backend spanning tasks, projects, HR records, attendance, leave, performance reviews and announcements
  • Full external client portal: invoices, estimates, proposals, reports, payment records, appointments, messaging and document e-sign
  • Dynamic role-and-permission RBAC with strict employee/client isolation and a default-deny posture
  • Agentic AI assistant that executes permission-checked portal actions, plus a multilingual public lead-capture chatbot
  • Real-time chat, notifications and presence over Django Channels and Redis
  • CRM with public booking, Daily.co video rooms, iCal invites, webhook lead intake and unsubscribe handling
  • DevOps hub with a Fernet-encrypted secret vault, access logging and re-authentication before reveal
  • Design-asset library, a marketing planner and internal staff-document sign-off

Outcomes

  • Consolidated roughly six categories of standalone tooling into one authenticated, permissioned backend behind a single versioned API
  • Established a reusable dynamic RBAC and default-deny posture that cleanly separates internal staff from external client accounts
  • Delivered resilient real-time infrastructure — WebSocket chat, notifications and presence — with a fail-soft cache and hardened origin validation
  • Shipped a Docker production deployment with health-checked services, PostgreSQL connection health checks and GitLab-driven CI/CD across dev and prod

More work