Permissions

Every permission Rostack knows about, what it lets somebody do, and the one thing the rank floor beneath it still decides. The list is generated from the same constant the product checks against, so it cannot quietly fall behind.

How a check runs

A permission is a string. Roles hand them out, individual additions and removals adjust the result, and the resolved list is stored on the staff record. An access check reads that stored list and nothing else: resolving roles at request time would cost a read of the roles document on every request, and this is the busiest path in the product.

Three things are then true of every check. A record that is not active holds nothing, whatever its list says. The rank floor below is re-applied at the moment of the check, because a rank can drop between the last resolve and this request. And the owner short-circuits before either.

Every permission

The name in the middle column is the one the permission editor shows; the id on the left is what an error message names when something is refused.

Permission	In the editor	What it allows
`members.view`	View the group roster	Open the roster and search it. Reading the product catalogue asks for this one too, as do the Feed and Reconciliation pages.
`staff.view`	See who is tracked as staff	See who is tracked as staff and open their records. The Roles page asks for it as well.
`staff.manage`	Track, suspend and retire staff	Track somebody by hand, suspend or reinstate a record, and retire one. Retiring keeps the record and empties its grant.
`roles.manage`	Create roles and decide what they grant	Create and edit roles, decide what each grants, and choose which Roblox ranks count as staff.
`activity.view`	See in-game time and session history	Read the minutes, messages and idle time your game servers report. The Quotas page asks for it too.
`sessions.view`	See the session calendar	See the session calendar.
`sessions.host`	Host a session and mark attendance	Claim a session, host it and take the register.
`sessions.manage`	Schedule, edit and cancel any session	Schedule, edit and cancel any session, including one somebody else is hosting.
`timeoff.request`	Ask for time off	Ask for time off. It is also the permission the Time off page itself requires.
`timeoff.approve`	Approve or deny time off	Approve or deny somebody else's request.
`goals.manage`	Set quotas and activity goals	Set the quotas and activity goals people are measured against.
`knowledge.view`	Read handbooks and guides	Read the handbook: the guides and policies addressed to your rank.
`knowledge.manage`	Write and publish articles	Write, publish and edit articles. Every edit is kept.
`ranking.view`	See ranking and its history	Open the Ranking page and read what has been changed there.
`ranking.run`	Change ranks and issue API keys	Change a rank, and issue the API keys that let a game server or bot do it. A rank that carries permissions still cannot be assigned by a key.
`promotions.recommend`	Recommend someone for promotion	Put a colleague forward for promotion, and back somebody else's recommendation. The Promotions page requires it.
`promotions.decide`	Approve or deny a recommendation	Approve or deny a recommendation.
`discipline.view`	Read disciplinary records	Read the disciplinary record: notes, warnings and the rank moves beside them.
`discipline.issue`	Issue warnings and strikes	Issue warnings and strikes.
`moderation.ban`	Ban a player from the experience	Ban a player from the experience. The list is what your game server enforces, and it records who issued each ban and why.
`payouts.view`	See payout runs and the ledger	See payout runs and the ledger. Both the Payouts and the Payroll pages ask for it.
`payouts.run`	Prepare and execute a payout run	Prepare a payout run and execute an approved one.
`payouts.approve`	Approve a run someone else prepared	Release a run somebody else prepared. No single role may hold this and payouts.run at once.
`audit.view`	Read the full audit log	Read the whole audit log, filter it and export it.
`workspace.manage`	Rename, change access, connect credentials	Rename the workspace, change how people join, connect credentials, and add or remove products.

The rank floor

Rostack authority is capped by Roblox authority: a seat can hold less than its Roblox rank allows, never more. That is what keeps a compromised Rostack account strictly less dangerous than the Roblox account behind it. The interesting part is how little of that cap an absolute number can actually express.

Roblox rank numbers carry no shared meaning between groups. One community runs on 1, 2, 3 and 255; another spreads its staff across the whole range. A floor of 200 on payouts therefore does not mean "senior" anywhere. In most groups it means "nobody but the owner", and the only way out would be renumbering the Roblox group itself, changing everybody's in-game perks and the whole role structure to satisfy a constant in a different product.

Worse, a number like that silently overrides an explicit decision. An administrator who maps their rank 3 Director role to payouts.approve has made a deliberate choice, checked against what they themselves hold and written to the audit log. A constant quietly discarding it is a control that fails confusingly rather than safely.

So the real ceiling is the role mapping. It is per workspace, explicit and reviewable, and it is defended by three checks an absolute number never provided: you cannot grant a permission you do not hold, you cannot map a role to a rank at or above your own, and a suspended record resolves to nothing at all.

What is left in the floor is the one thing that is true in every group however it numbers itself. Reading is open to anyone tracked, so every view permission sits at rank 0:

floor of 0

members.view
staff.view
activity.view
sessions.view
knowledge.view
ranking.view
discipline.view
payouts.view
audit.view

Every other permission sits at 1, which is not a claim about seniority. Somebody who has left the group is mirrored here at rank 0, so a floor of 1 says only that acting requires being a current member rather than a former one.

The owner

The owner holds every permission implicitly. The resolver writes them the whole list rather than storing a fixed one, so a permission added in a later release cannot lock them out of their own workspace, and their ownership was verified against Roblox when the workspace was connected.

Ahead of the ceiling, not through it

An access check returns true for the owner before it consults the stored list or the rank floor. That is why a group whose ranks are all single digits is never locked out of its own payouts, and it is the same exemption that lets the owner map roles to ranks that other administrators may not touch.