AOL Mail Creator

Automated Email Account Operations Platform

Project Overview

This project is a private, Node.js-based automation platform developed to manage a structured email account onboarding workflow through both a command-line interface and a centralized web dashboard.

The system coordinates browser automation, user-data generation, phone verification, process monitoring, error recovery, screenshot capture, and structured data storage. It was designed for controlled internal use, with emphasis on operational visibility, repeatable execution, and centralized management of multiple automation instances.

---

The Challenge

The original workflow required several repetitive and time-sensitive steps:

• Preparing unique user information
• Opening and completing registration forms
• Validating username availability
• Requesting a verification number
• Waiting for an SMS verification code
• Handling failed, rejected, or expired verification attempts
• Saving successfully created account information
• Monitoring multiple running processes
• Reviewing failures and retrying interrupted operations

Managing these steps manually was slow, inconsistent, and difficult to scale. Running multiple sessions also introduced challenges around process coordination, duplicate data, file conflicts, visibility, and error recovery.

The objective was to create a controlled automation system that could centralize these operations while keeping sensitive logic and service credentials protected.

---

Solution

I developed a modular automation platform that combines a browser-controlled workflow with a lightweight management dashboard.

The application supports two operating modes:

Web Dashboard

The dashboard provides a centralized interface for starting, monitoring, and managing multiple automation processes. It displays live activity updates, process states, success and failure events, and operational logs.

Command-Line Mode

The command-line interface provides a lightweight execution option for individual sessions, testing, diagnostics, and controlled operation without the dashboard.

Both modes use the same underlying services and business logic, which keeps the application maintainable and avoids duplicating workflow code.

---

Core Features

Browser Workflow Automation

The system uses a browser automation layer to interact with registration pages and complete required user-input steps.

The public version does not disclose:

• Target page selectors
• Page-state detection rules
• Navigation conditions
• Form submission logic
• Challenge-screen handling
• Validation detection
• Browser launch configuration
• Timing and retry patterns

This prevents the portfolio description from functioning as a technical reproduction guide.

Dynamic User Data Generation

A dedicated data-generation service prepares unique profile information for each workflow. Generated records are checked against previously stored data to reduce duplication.

The generation logic is separated from browser automation, allowing it to be maintained or replaced independently.

Verification Service Integration

The application integrates with a third-party verification provider through a dedicated service layer.

This layer is responsible for:

• Checking service availability
• Requesting a temporary verification number
• Monitoring verification status
• Receiving verification codes
• Confirming successful completion
• Cancelling failed or expired requests
• Returning normalized responses to the main workflow

Provider-specific endpoints, action names, authentication parameters, country settings, and response parsing rules are intentionally omitted.

Multi-Instance Process Management

The web server can launch and supervise multiple automation workers as separate child processes.

Each worker reports structured state updates back to the dashboard. This creates separation between the user interface and automation runtime while allowing centralized monitoring.

Real-Time Activity Monitoring

The platform streams process updates to the dashboard using server-driven communication.

The interface can display:

• Current workflow stage
• Active instance status
• Informational messages
• Successful completions
• Recoverable warnings
• Failed operations
• Retry states

This makes long-running sessions easier to observe without directly accessing each process terminal.

Structured Account Storage

Successfully completed records are saved to a structured spreadsheet file.

Stored data may include:

• Account identifier
• Generated profile name
• Associated phone number
• Creation timestamp
• Username
• Internal workflow metadata

Sensitive fields are not shown in this portfolio document.

A file-locking mechanism is used to reduce the risk of conflicting writes when several instances attempt to update the same output file.

Screenshot and Audit Support

The system can capture screenshots after important workflow stages. These screenshots provide visual confirmation and help investigate unexpected behavior.

Screenshots and generated records are stored in separate output directories to keep operational data organized.

Error Recovery

The application contains categorized error-handling logic for common failure conditions, including:

• Verification number rejection
• Temporary service unavailability
• Verification timeout
• Invalid or unavailable user identifiers
• Browser navigation failure
• Interrupted sessions
• Provider-side errors
• Duplicate records
• Unexpected page states

Recoverable errors follow controlled retry or cancellation paths. Critical failures are reported to the operator instead of continuing silently.

---

High-Level Architecture

Web Dashboard / CLI
        |
        v
Workflow Orchestrator
        |
        +-- Browser Automation Service
        +-- Verification Service
        +-- User Data Generator
        +-- Spreadsheet Storage Service
        +-- Logging and State Service
        +-- Utility and Validation Layer

The system follows a service-oriented internal structure. Each major responsibility is isolated into a separate module, making the codebase easier to debug, extend, and maintain.

---

Technology Stack

• Node.js for the application runtime
• Puppeteer for browser-controlled workflows
• JavaScript for application and dashboard logic
• HTML and CSS for the web interface
• Server-Sent Events for live dashboard updates
• Child Processes and IPC for worker management
• Spreadsheet Processing for structured record storage
• Randomized Data Utilities for controlled profile generation
• Mutex-Based File Locking for concurrent write protection

---

Security and Access Controls

Application Access Gate

The application includes an access-password validation step before allowing the main workflow to start.

The public portfolio version does not expose:

• Password values
• Stored hashes
• Validation constants
• Authentication code
• Access-control implementation details

Configuration Separation

Service credentials and operational configuration are stored separately from the primary workflow modules. This reduces accidental exposure inside application logic and makes environment-specific configuration easier to manage.

For a production deployment, these values should be stored in environment variables or a dedicated secret-management service instead of being committed to the repository.

Controlled Logging

Operational logs are designed to report workflow states without requiring the dashboard to inspect internal application memory.

Public documentation excludes:

• Raw provider responses
• Authentication tokens
• Full phone numbers
• Passwords
• Internal request payloads
• Sensitive failure messages

Process Isolation

Each automation worker runs as a separate process. This reduces direct coupling between concurrent sessions and allows failed workers to be stopped or restarted without terminating the full dashboard.

Concurrent File Protection

A mutual-exclusion mechanism protects spreadsheet operations when multiple workers attempt to save records simultaneously.

Manual Intervention for Restricted Challenges

The system does not publicly document or expose methods for bypassing protected challenge mechanisms. Where a workflow requires human verification, the process is paused and transferred to an authorized operator.

---

Public Portfolio Protection Measures

To protect the client, the platform, and the original implementation, this case study deliberately excludes all copy-sensitive details.

The following information is not included:

• Complete source code
• Repository structure beyond a generalized architecture
• Browser selectors
• Registration URLs
• Verification provider identity and endpoints
• API query formats
• Authentication keys
• Password hashes
• Internal event names
• Timing values
• Retry thresholds
• Country and operator configurations
• Exact user-data generation rules
• Challenge detection logic
• Anti-abuse or anti-bot handling details
• Spreadsheet schema containing sensitive fields
• Deployment scripts
• Production configuration

This allows the project to demonstrate engineering capability without turning the portfolio entry into a reusable automation blueprint.

---

My Responsibilities

I was responsible for:

• Designing the overall automation workflow
• Structuring the application into reusable services
• Developing the browser automation layer
• Integrating the external verification service
• Building the command-line workflow
• Developing the web-based management dashboard
• Implementing real-time process updates
• Managing child processes and inter-process communication
• Creating structured logging and state reporting
• Adding spreadsheet-based persistence
• Preventing duplicate records
• Handling concurrent file access
• Designing retry, cancellation, and recovery flows
• Organizing configuration and operational output
• Preparing technical documentation for future maintenance

---

Engineering Highlights

Modular Service Design

Browser operations, verification, data generation, storage, logging, and utilities are separated into focused modules. This minimizes coupling and makes changes easier to test and maintain.

Shared Logic Across Interfaces

The CLI and web dashboard use the same core workflow instead of maintaining separate implementations.

Observable Long-Running Processes

Structured state messages provide visibility into each worker's progress and allow the dashboard to present meaningful updates in real time.

Defensive Error Handling

The system distinguishes between recoverable and critical errors. It can retry temporary failures, cancel unusable verification requests, skip invalid records, and terminate safely when operator action is required.

Safe Concurrent Storage

File locking reduces data corruption and record loss when several workers complete at nearly the same time.

---

Outcome

The platform was designed to convert a repetitive, multi-step process into a centralized and observable workflow.

It improved the operational structure by:

• Reducing repetitive manual data entry
• Centralizing multiple running processes
• Providing live visibility into each workflow
• Standardizing record storage
• Reducing duplicate entries
• Improving failure reporting
• Supporting controlled retries
• Simplifying troubleshooting through logs and screenshots
• Keeping sensitive implementation details separated from public documentation

---

Confidentiality Statement

This project was developed for a restricted internal workflow. The version presented in this portfolio is intentionally abstracted.

It demonstrates my experience with browser automation, third-party service integration, process orchestration, real-time dashboards, concurrent file operations, defensive programming, and technical documentation without disclosing information that could enable unauthorized duplication or misuse.