System Overview
A practical overview of the main remoteEaze applications, packages, and responsibilities.
Last updated
remoteEaze is organized around three visible application surfaces and a set of shared packages.
Main applications
Admin application
The admin area is the back-office control surface. It includes foundation setup, organization structure, configuration, CRM operations, loans, close of business, delivery controls, notifications, and activity review.
Its navigation is grouped into five business-oriented areas:
- Foundation
- Organization
- Business Configuration
- Operations
- Processing & Monitoring
Field workbench
The workbench is the lighter operational surface used for day-to-day field execution. The current workbench focuses on:
- customers
- accounts
- transactions
- sync monitoring
The workbench is designed around intermittent connectivity. It keeps local state for offline-first flows and uses synchronization to move work back to the server when a connection is available.
Documentation application
The documentation site is a separate application used to explain how the system works. Its purpose is to present a current, readable view of the platform and not to act as an operator console.
Shared backend and package structure
The backend is built as a set of focused modules. The major active module areas include:
- access control
- organization management
- customer and ledger operations
- financial and contract configuration
- transactions, scheduling, and close-of-business processing
- loan lifecycle operations
- notifications and delivery
- audit, licensing, and synchronization services
Shared packages provide the common building blocks:
- configuration loading and validation
- database schema and client access
- shared types and utilities
- custom field and rule logic
- queue and background-job support
- ledger and accounting support
- shared UI components
Why this structure matters
This layout keeps the system understandable in practical terms:
- shared rules live once and can be reused
- business modules can evolve without rewriting the whole system
- the workbench can support offline execution without duplicating every back-office concern
- supporting services such as storage, delivery, and observability can be reused across domains