Roles and permissions
What OWNER, ADMIN, and MEMBER are each allowed to do in a Gigadrive organization.
Every membership carries exactly one role. The role decides who can change the plan, the payment method and the budget, and who receives the emails when something breaks.
| Role | Meaning |
|---|---|
OWNER | Full organization administrator, and the person who created the organization |
ADMIN | Organization administrator with product and membership management access |
MEMBER | Regular member without administrative permissions, and the default for new memberships |
What each role gates
| Capability | Required |
|---|---|
| Read the organization, its members, and its product access through the API | Any role |
| Change the plan, seat count, budget, billing details, or payment method | OWNER or ADMIN |
| Receive operational alert email, such as an application going down | OWNER and ADMIN, at their account email |
| Use Gigadrive Network itself | Membership, plus organization product access, plus an assigned seat on seat-licensed plans |
Alert email deliberately goes to administrators rather than to the billing contact. An organization can point billing at a finance mailbox, which is the wrong place to send "your applications are down".
The last row is the one that surprises people: a role is not a product entitlement. A MEMBER of an organization whose Pro plan has no spare seat can open organization admin surfaces and still be refused by the product itself. Product access walks through that resolution.
OWNER and ADMIN
Nothing in the platform treats the two differently at request time. Both pass the administration check, both receive alerts, and both can change billing.
The one place they diverge is the organization ownership quota. It counts only OWNER memberships, so being an ADMIN of ten organizations does not stop you from creating your own. See Organization settings for those numbers.
Changing a role
Roles are fixed once a membership exists
There is no API, console page, or CLI command that changes a member's role, and none that removes a membership. The
creator's OWNER role is written when the organization is created and stays that way.
MEMBER is the schema default for new membership rows, so it is what a join flow would produce. Nothing writes such a row today. Members covers what is readable in the meantime.
Machine access has no role
An API key is bound to an application, not to a person, and its permissions come from its scopes rather than from a membership. A key keeps working if the person who created it never signs in again. That is the intended way to give a build system or a script access to one application without granting it anything else. See API keys.