How bans are structured

If you just want to issue a ban, you don’t need this page — see Ban a player instead. This page is for when you need to know exactly what a ban is made of and how it behaves once issued, regardless of where it came from. For connecting an external source, see Sync an external ban source; for the automatic cross-community signal, see Cross-community ban visibility.

Fields of a ban

Field	Description
Coverage	The identities the ban is enforced against, fixed at the moment it is issued — see below
Reason	Free-text explanation, shown wherever the ban appears
Duration	Permanent, or an expiry date/time. An expired ban stops enforcing on its own — you don’t need to revoke it.
Scope	Every server in your organization (including ones added later), or a list of named servers
Status	Active, Expired, Revoked, or Removed from source — derived from the record, never stored

A ban targets a player, not a single identity — it’s enforced against its coverage, the set of identities it was decided against: the identity it was issued against, plus the identities (Steam, EOS, BattlEye, Mojang) your own servers had already linked to that player at that moment. A player who presents any identity in that set matches the ban, not just whichever one triggered it.

Coverage is taken once, at the decision, and never recomputed. An identity linked to the player afterwards does not widen the ban, and re-ranking the player’s identities does not narrow it. That is deliberate: a coverage that tracked the player’s live identities would let one observation extend an already-issued punishment to a new account of that person without anyone deciding it.

Manual vs. imported

A ban gets into heliana one of two ways:

• Manual — an admin issues it directly, either by running the Ban player automation or with the Ban player button on the player’s Bans tab; or an automation issues it automatically in response to an event or a schedule.
• Imported — it comes in from a connected external ban source (BattleMetrics or a Remote Ban File, which also reads a Community Ban List export), set up on the Bans → Sources tab. A sync writes straight into the ban records scoped to that source — there’s no access list or tag in between, and no background scheduler either. You run a sync by hand with Sync now. The coverage of an imported ban is exactly the identities carried by the source’s own entry — heliana never adds identities of its own observation to it, and a later sync refreshes the entry’s reason and expiry without rewriting its coverage.

Either way, the ban shows up in the same place: the Bans tab on the player’s profile.

Who issued it. Nobody, as far as the record goes: a ban has no “issued by” field at all, whoever made it. A ban you made by hand is in the Audit log as a ban:create entry with your name on it; a ban an automation made is in that automation’s run history (a run fired by an event or a schedule writes no audit entry; a manual run is logged as automation:run); an imported ban carries the source it came from.

Revoking

Revoking a ban lifts enforcement immediately and marks it Revoked. A revoked ban drops out of cross-community visibility entirely — only bans still enforcing are shown there.

Cross-community ban visibility

The cross-community signal carries matching bans from other heliana communities that are still enforcing — read-only and automatic. The filter is the same one that decides whether a ban bites at all: revoked, expired and absent entries are left out, so an old punishment another community has let lapse never follows the player around. There’s no sharing step, no consent request, and no opt-in: any community using heliana can see any other community’s enforcing bans on a matching player, as an advisory signal. It’s informational only — it never bans a player on your servers by itself.

It appears on the player’s Bans tab, in an Other communities block separate from your own decisions, and its rows carry no action — neither Revoke nor Exclude means anything on someone else’s decision. A row is a much shorter record than a ban of your own: reason, the date the other community decided, and the expiry (or permanent). No scope, no coverage, no status, and no community name — the other organization’s servers, the identities it decided against, and its own identity all stay on its side. A row can be a ban that community imported from a source rather than issued by hand, since an imported entry is a ban record of theirs like any other; a single entry on a widely mirrored list therefore arrives as one row per community holding it. Reading the block takes the ban read permission — the same one the rest of the tab needs; the tab itself is not gated by it. Without the permission the block says so, rather than standing empty as if the player were clean elsewhere.

A match goes by the identities in common: heliana compares the identities the player is known by now against the identities each ban was decided against, and one in common is a match — so a ban in another community follows the person, not one single ID. The identities a ban was decided against do not grow when the person links new accounts afterwards, so no observation of ours extends someone else’s punishment to a new account.

Exceptions

An exception excludes one player from enforcement of a ban you don’t own — an imported one — without touching the ban record itself. It never applies to a ban you issued yourself; to stop that one, revoke it — and heliana refuses to record an exception at all while a ban of your own is still in force on that player (OwnBanExists). The player’s Bans tab reflects that split: an imported entry offers Exclude (and Remove exclusion once excluded), one of your own offers Revoke. An exception carries a scope of its own — every server in your organization, or one named server, with the ban still enforcing everywhere else. The Scope field in the exclusion dialog on the Bans tab picks between the two; it defaults to every server, so an exclusion you confirm without touching it is org-wide. The ban’s Excluded line then shows that scope — All servers, or a count of servers, never the server’s name — because the tab marks a ban excluded as soon as any exception suppresses it; without that line, an exclusion on one server would look exactly like an org-wide one while the ban kept enforcing elsewhere.

An exception’s coverage is not frozen the way a ban’s is: it’s the player’s current identities, read on every enforcement check. It suppresses a ban when the two coverages share at least one identity — an overlap, not one set containing the other. An identity linked to the player later starts falling under the exception’s coverage; the ban’s own coverage does not grow to match it.

A reason on an exception is optional. Recording one is worth the keystrokes — it is what the ban row shows on its Excluded line, next to the scope — but heliana accepts an exception without it.