# Legioner Solutions — Access Automation & Operations Leandro Pareja | Project report ## Project overview I built and maintained application workflows that connected community membership, access requests, staff decisions, and operational information. Legioner Solutions brought those activities into a structured system using Node.js, discord.js v14, MongoDB, and Google Sheets integrations. My work combined application and integration development with systems administration: managing server configurations, deploying applications, maintaining services, and troubleshooting technical issues. The goal was to make recurring administrative work easier to coordinate while keeping staff responsible for approval decisions and in-game fulfillment. 20,000+ Community members Membership-based scale, not a concurrent-user or throughput measurement. ~70% Less manual administration Project-reported estimate across automated activities. ## The workflow at a glance The application coordinates the request. Staff make the decision and complete the fulfillment. ### 01 → 04 From request to completion - User input Submit a guided request Commands and forms collect details. Selected handlers check roles, membership, or pending state. - Application state Record & queue the work A request is stored in MongoDB and presented to staff as a work card. - Human decision Review & fulfill Staff approve applicable requests and carry out the in-game fulfillment. - Completion Update & notify Record completion, refresh the queue, disable completed controls, and notify the requester. Supporting integrations External trackers → operational displays Configured source filtering, parsed telemetry, server status, and scheduled updates. Google Sheets ↔ application records Service-account import/export utilities and safeguards for manually corrected data. A simplified view of the documented request lifecycle. Authorization is distributed across selected handlers; not every workflow follows an identical sequence. ## The operational problem Membership approvals, access requests, and resource fulfillment involved recurring coordination between users and staff. Free-form intake made the status of outstanding work harder to follow. I replaced that intake with guided inputs, persistent requests, staff-facing queues, and completion notifications. The system needed to connect several kinds of information: platform identity, configured community roles, request details, stored records, and external server telemetry. Each integration had a different purpose and needed to be handled within its own trust boundary. ## What I built ### Identity and access workflows The platform supplied an authenticated actor and interaction context. Selected commands checked configured role groups before modifying membership state. Cross-community onboarding checked primary-community membership and the required role before assigning secondary roles. ### Requests, staff queues, and notifications Commands, buttons, and forms routed interactions to the relevant application handler. Applicable request workflows checked for an existing pending request, created an incomplete MongoDB record, and published a staff work card. After fulfillment, the application updated completion state and coordinated the queue and requester notifications. ### Telemetry and external services Configured tracker messages passed through sender and channel matching before being parsed into operational state. A public server feed supplied population and metadata for scheduled displays. External database reads supported player analytics and leaderboard aggregation. ### Data and administrative integrations MongoDB held member approvals, requests, and completion state. Google Sheets connected through a service account and import/export utilities. Local JSON stored tasks, timers, and snapshots; in-memory maps and sets held temporary state. ## Engineering decisions and safeguards I separated workflow coordination from human fulfillment. The application made work visible and tracked its state, while staff retained responsibility for decisions that required their review. Typed command options, required form inputs, duplicate-pending-request checks, private responses in selected workflows, and configured telemetry-source matching supported more predictable operations. Persisted reminders restored scheduled work after application restarts. Character-record removals used a process-local mutex to serialize a helper’s read/modify/write path. Records included a lastModified marker, and spreadsheet imports skipped retained records already marked as manually corrected. RAW spreadsheet writes helped preserve the intended input values. These safeguards addressed specific failure paths. The mutex was not a distributed lock, and the local JSON, maps, sets, and temporary state were process-scoped. Handler-level role checks also should not be read as evidence of a single, universal authorization layer. ## Explore the technical implementation The detailed diagram below connects the access workflow with telemetry, storage, and integrations. Open it to inspect the architecture, then select a node for an illustrative code example. Explore the interactive technical architecture and illustrative code at https://leandropareja.com/legioner-solutions/ ## Results and how to read them The application supported a community of more than 20,000 members. The reported reduction in manual administration was approximately 70% across automated activities. These figures describe community scale and a project-reported estimate; they are not independently benchmarked throughput, concurrency, or performance measurements. The practical result was a more structured way to collect requests, track outstanding work, and communicate completion. The supporting project document explains the implementation context. The code examples on this page are independently authored illustrations, not production source or proof that every illustrated control was implemented. ## What I would improve next The next hardening priorities follow the points where permissions, persistent state, and external messages meet: - Consistent authorization: apply appropriate checks to every mutation. - Atomic request deduplication: prevent simultaneous requests from creating duplicate work. - Revision-checked writes: detect changes before replacing records. - Retry and reconciliation: recover when a database update succeeds but a notification fails. ## What I took from the project This work connected access management, backend application logic, persistence, integrations, and day-to-day operations. It reinforced the importance of making state transitions explicit: who requested an action, what checks applied, who fulfilled it, and whether completion was recorded and communicated. Engineering takeaway: reliable automation needs clear ownership of decisions, durable workflow state, and a recovery path when connected systems disagree. ## Technology and supporting material Node.js · JavaScript · discord.js v14 · MongoDB · Google Sheets API · JSON persistence · async-mutex · Windows and server administration. Read the supporting project document Based on the supplied Legioner Solutions project document and resume. Implemented behavior and future hardening priorities are distinguished above. Homepage network activity is a separate visualization using simulated events. Full report: https://leandropareja.com/legioner-solutions/