Global Control Admin

Documentation for the admin panel of Global Control, a CRM and marketing automation platform for agencies and their clients. The panel is the back-office tool used to run the platform itself: admin accounts, users, white-label platforms, the third-party integration catalog, satellite servers and custom-domain SSL. It works alongside Global-Control-Frontend (the customer app) and Global-Control-Server (the API).

The source code is not included in this repository. This is client work and the code is proprietary. This repo only holds documentation: this README, a reverse-engineered product spec (PRD.md), and two diagrams in screenshots/. Everything here was written from a read-through of the actual codebase. Hostnames, credentials and security specifics are left out on purpose.

What it does

The customer app lets users connect third-party services through tags and workflows. Those services are not hardcoded. Each one is defined in the database as an integration with an authentication method, triggers and actions. This admin panel is where those definitions are built, tested and published. It also manages who can log in to the platform and which white-label brands and servers exist.

Architecture

Admin user -> Admin panel (Vue SPA) -> Backend admin routes -> MongoDB
                                                       |
                                  integration catalog read by the customer app

How an integration is built

• A single-page Vue 3 app with one side-menu layout and a few standalone pages (login, error).
• About 105 Vue files, 19 Pinia stores and a small helper layer: one endpoint map and one Axios wrapper that adds the bearer token and normalizes responses to {data} or {error}.
• All data comes from the backend. The panel has no sockets and no local business logic.
• Deployment is a manual build followed by a copy to the web server directory. There is no CI.

Tech stack

Area	Tools
Framework	Vue 3 (Composition API), Vue Router 4, Pinia
Build	Vite 2, plain JavaScript
Styling	Tailwind CSS 3, the Icewall admin template
HTTP	Axios behind a fetch wrapper
Forms	vee-validate, Yup, Vuelidate
Code editing	Ace editor for the JavaScript snippets in integration definitions
Other UI	CKEditor 5, SweetAlert2 toasts, Tippy, Tom Select, Litepicker, Dropzone, Lucide icons, Chart.js

Core features

• Admins. Create and manage admin accounts.
• Users. Paginated list with filters, access level, status, white-label platform assignment and a user dialog for editing.
• Connected platforms. See which users are linked to which platforms and move a user to a different owner account.
• Platforms (white-label). Create and edit tenant brands with name, slug, URLs, logo upload, status and feature flags.
• Integration catalog. All, configured and queued lists, with status counts (live, pending, new, in queue, error, disabled). Create and edit the catalog entry with logo, category, type and login details.
• Integration builder. A tabbed editor for one integration:
  • Authentication: API key or OAuth 2, with request definitions, fields, a connection label template and optional JavaScript.
  • Triggers and actions: the HTTP request, input fields, output fields, sample output and dynamic fields, with a test run against a test account.
  • Response codes: status messages and headers per integration.
  • Test accounts for trying an integration end to end.
• Categories and types. Simple lists that group integrations.
• Satellite servers. Register the servers that process queue work.
• SSL domains. Review custom domains and their A records, re-fetch a certificate or re-validate a domain, with shortcuts to external DNS checkers.

Data model

Entities managed by the panel (the database itself lives in the backend):

• Admin and User: name, email, password, access level, status, linked platforms.
• Platform: name, slug, URLs, logo, status, development flag and feature switches.
• Integration: title, logo, category, type, status level, lock state, login details.
• Authentication config: API key or OAuth 2 definition with fields, request definitions, token handling and JavaScript snippets.
• Trigger and action: key, name, description, input fields, request definition, output fields, sample output, test results.
• Test account: a sample authenticated account per integration.
• Integration settings: response-code messages and headers.
• Category and type: title and status.
• Satellite server: name, address, key, position, enabled flag.
• SSL domain: domain and DNS record data.

Known limitations

• Some screens are placeholders. The dashboard is the original template with made-up numbers and no data behind it. Monitoring, publishing and team management are empty pages. Versions, history, sharing and analytics are static.
• No billing or queue log screens.
• Authorization lives in the backend. The panel has no role-based screens, so every logged-in admin sees the whole menu.
• Auth edge cases are incomplete. Expired sessions and logout on an API error do not always clear state, and login errors use a browser alert.
• Dead and duplicate code. A backup folder, a zip build, a log file, editor settings and a stray second README are tracked in git, and the SSL dialogs are copied from the satellite dialogs.
• Environment files are tracked in git. They should be untracked and kept out of history.
• One hardcoded host in the OAuth form means that screen only works against the production API.
• Heavy and aging dependencies. Vite 2, CKEditor 29 with five builds installed and one used, Chart.js 2, an old spreadsheet library and several installed packages the app never uses. Both package managers have lockfiles in git.
• A few very large components, some past 1,200 lines.
• No tests, no linting, no CI.
• English only.

Author

Ammad Sarfraz

This repository contains documentation only. The Global Control platform and its source code belong to the client.