A right isn't a grade. A right isn't an admin.
In Discord bots and classic guild managers, you get to choose between member, mod and admin. Three levels, zero granularity. Game Org provides a grid of atomic technical rights: each sensitive action has its own right, assignable separately, without you having to hand out everything to delegate a piece of it.
- Dozens of atomic rights, not three grades — "Can validate an officer promotion", "Can create a secret event", "Can edit their section's training", "Can manage member rights". Each sensitive action has its own dedicated right, assignable to anyone you choose
- Logical cascade, not combinatorial explosion — the Org Admin right covers everything, Training Admin covers all training actions, Events Admin covers every event type. You set the top of the cascade, the rest follows — no need to tick thirty boxes
- Explicit scopes — global, their section, or their own content. A section lead can edit their section's training without seeing anyone else's. A mission contributor can edit their own missions, not a neighbour's
- Zero catch-all role — no "nice mod who can still do everything because we trust them". Trust doesn't get coded, rights do
Proposing isn't validating.
Most tools run on the logic "if you can do the action, you can trigger it alone". Game Org systematically separates the right to propose from the right to validate. An officer can suggest a promotion without signing it — a higher-ranking officer decides. The hierarchy is wired, not implicit.
- On promotions, two rights systematically separated — HR can propose and HR can validate, for each of the 4 grade tiers. A non-commissioned officer can be allowed to propose an officer without being able to validate one. Eight atomic HR rights, not one admin button that opens everything
- Same logic on training — a member completes their training, but a dedicated right Validate their section's training is required to mark it as passed. The member doesn't award themselves their own certificate
- Rejections require a written reason — if a proposal is refused, the requester receives the reason. No message vanishing into the void, no "I refused but I won't tell you why"
- Impossible to self-promote, impossible to unlock the "just this once" exception on a late-night voice call. The workflow is a safeguard against decision fatigue
Your org isn't a public catalog.
Some well-known gaming tools — fleet catalogs, community wikis, open registries — are built to be indexed by Google and scraped by rivals. Your crew compositions, your assignments, your tactical roster: exposed to the world. Game Org does the opposite: your org has no public page by default.
- No public URL for your fleet, your roster, your events, your training. Nothing guessable from the outside. An outsider trying /orgs/your-name hits a login screen, not your roster
- Direct contrast with Fleetyards and peers — they're built as showcases, Game Org as a vault. Two opposing philosophies, a choice to make depending on what you consider a competitive edge
- Your org's public content is zero by default. No opt-out to understand, no checkbox to uncheck in some obscure settings page. You are invisible until you decide otherwise
- Your competitors see nothing — not your mission compositions, not your upcoming events, not who's climbing ranks at your place. They know you exist, they don't know what you do
Every org, a silo. Zero lateral spill.
The Game Org server systematically filters data by org identifier. Every request is tied to one org and one org only — a user authenticated on org A will never see data from org B, even if they're a member of both on Discord. No global Game Org dashboard aggregating your data with your rivals'.
- Tenant-level isolation — a member belonging to multiple orgs switches from one to another, never in parallel. Same logic as two separate Discord servers: you're on one, or on the other, never both at the same time
- No rights superposition — your Org Admin rights on one org grant no access on another. Each org manages its own rights, its own grades, its own hierarchy
- On every fetch, the server checks which org you're on before returning a single byte. The check is systematic, not optional, not bypassable by a hand-crafted URL. Impossible for another org's data to reach you by accident
- No shared config template leaks — you configure your org, your grid is yours, your labels are yours. Nothing crosses over, not even your organizational structure
No account, no password, no credentials to steal.
Every time a tool asks you for a password, you create an attack surface. A password reused elsewhere, a phishing attempt that lands, a login database that leaks — and your org is compromised by a mistake that isn't even yours. Game Org has no local account: authentication goes through Discord, the source-of-truth identity your members already use.
- No Game Org password to manage, so nothing to forget, nothing to reset, nothing to get stolen. No local login database to protect on the infrastructure side
- Access tied to Discord — when a member is removed from your org (External resignation on the HR module), their Game Org access drops automatically through Discord propagation
- No orphan sessions lingering six months after an officer's departure. No ex-member holding on to a forgotten token in a tab on some old PC
- If Discord locks an account (TOS violation, compromised account), Game Org reflects it. One login, one source-of-truth identity, no divergence to monitor
FAQ
Frequently asked questions
What concretely prevents an officer from self-promoting?
The separation between HR can propose / HR can validate. Proposing a promotion and validating it are two separate rights, assigned to different hierarchical tiers. A non-commissioned officer can propose an officer, they don't have the right to validate — that right is reserved for the higher tier. If an officer tries to self-promote, the action lands in a higher-ranking officer's queue, who accepts or refuses with a mandatory reason. Org Admins, who technically have the full cascade, leave a trace in the HR activity feed on every decision — even they can't act in silence.
Can another org see my data?
No. Every request is scoped on the server side by the org identifier. A user authenticated on org A who tried to access a resource from org B would receive a refusal, not accidental data. A member belonging to multiple orgs switches between them, never in parallel: they're on one or the other, like two separate Discord servers. No global view aggregating, no shared template leaking, no rights crossing over. Your rivals can be Game Org clients like you, they will never see your compositions.
What happens if a member leaves Discord or your org removes them?
Two cases. If they leave Discord themselves (or their account is locked), their Game Org access drops on the next identity check — they are no longer authenticable. If your org removes them via the HR module (External resignation), Discord propagation strips the member role automatically: no more access to internal channels, no more access to Game Org spaces tied to that role. Their history stays archived on Game Org for audit, but they can no longer view or modify anything. If they later apply through the Recruitment module, their old file resurfaces flagged "Suspect".
Can Game Org prevent a deliberate leak (copy-paste, screenshot)?
Honestly: no. No SaaS tool can prevent a legitimate user from taking a screenshot of what they legitimately see — at worst, you won't be more exposed than a screenshot of your Discord. What Game Org can do is minimize what each user legitimately sees. Least-privilege taken seriously: a recruiter with only the right View applications sees nothing else. A member of one section has no access to other sections' missions. The smaller the surface exposed to each role, the less far a potential leak can reach. Game Org doesn't promise the impossible, it reduces the perimeter of the possible.
How can I know, at any time, who has which rights in my org?
The Rights Management module, accessible to Org Admins in full view, and to section leads in a restricted version (who manage only the rights of their own members). In two clicks, you see who can do what, on which module — no need to dig through ten different screens or reconstruct a table by hand. A new staff member taking over a position can audit the rights in place within five minutes of taking the role, without waiting to hit a blocked action before understanding who can do what. Promotions, reserves and exclusions on HR are also traced in the HR activity feed — the rest of the rights changes are consulted directly in the Rights Management module.
How does Game Org technically protect the data?
Compartmentalized architecture: application backend separated from the database, DB access only through the internal API — no direct exposure. All user traffic goes over SSL/TLS, no exception. Every API request is authenticated and scoped by org identifier before reaching the data layer. The architecture is built for strict multi-tenancy and scaling up. We don't publicly communicate on the physical location of servers or low-level infrastructure details — these evolve with the platform.