--- title: "Enterprise Roles" description: "How enterprise roles (Owner, Admin, Billing manager, Member) differ from organization roles, and who in your company should hold each" --- An Enterprise account has two layers, each with its own roles: * **The enterprise** is your company: its email domains, sign-in rules, people and contract. Enterprise roles decide who manages those. * **Organizations** sit inside the enterprise and own apps. Organization roles decide who can see and ship each organization’s apps. The two are separate. An enterprise role gives no access to any app, and an organization role gives no say over the enterprise. One person can hold both. ## Enterprise roles Everyone who signs in with a managed account at one of your domains (through Google Workspace, Microsoft Entra ID, or your [SAML connection](/enterprise/saml/)) is a Member of your enterprise automatically. When Shorebird sets up your enterprise, you name its Owners, Admins and Billing managers and who should own your organization; everyone else joins as a Member. From then on, Owners change roles from the **People** tab of the **Enterprise** page in the [Shorebird console](https://console.shorebird.dev). Owners, Admins and Billing managers find **Enterprise** in the sidebar and in the account menu. | | Member | Billing manager | Admin | Owner | | ---------------------------------------------------------------------------------------------------- | ------ | --------------- | ----- | ----- | | See every organization, app, person and API key | | | ✅ | ✅ | | See activity across organizations | | | ✅ | ✅ | | Read the enterprise [audit log](/enterprise/audit-logs/) | | | ✅ | ✅ | | Download the [access report](#access-report) | | | ✅ | ✅ | | Add people to any organization and change their role | | | ✅ | ✅ | | Make someone an organization’s owner | | | ✅ | ✅ | | Remove a person from every organization at once | | | ✅ | ✅ | | Remove guests and set the guest policy | | | ✅ | ✅ | | Set default organizations | | | ✅ | ✅ | | See service accounts and revoke API keys | | | ✅ | ✅ | | Create Auditor service accounts and their keys | | | ✅ | ✅ | | Change enterprise roles | | | | ✅ | | [Require a sign-in method](/enterprise/saml/#require-a-sign-in-method-for-your-domains) for a domain | | | | ✅ | | Create the [SCIM](/enterprise/scim/) account | | | | ✅ | | See billing, usage and invoices | | ✅ | | ✅ | | See and download contracts | | ✅ | | ✅ | Only an Owner can create or revoke the SCIM account’s keys, or delete it. An organization’s new owner must already be a member of it, and if its current owner holds an enterprise Owner, Admin or Billing manager role, only an enterprise Owner can make the change; see [On the Enterprise plan](/account/access-and-ownership/#on-the-enterprise-plan). An enterprise always has at least one Owner; the last one can’t be demoted, and an Owner can’t be removed until they’re given another role. [Deactivating](#deactivate-someone) a person takes them out of every organization and app in the enterprise and revokes their invitations, sessions and API keys. Guests are people outside your domains who belong to one of your organizations. The [guest policy](#guest-policy) decides whether organizations can add them. Default organizations are ones that your enterprise’s Members join on their own, as a Viewer or Developer, whenever they sign in with a managed account through Google, Microsoft or your SAML connection. Owners, Admins and Billing managers don’t join them; add them to an organization yourself if they need app access. Someone removed from a default organization rejoins it the next time they sign in. To keep someone out, [deactivate their account](#deactivate-someone), which also stops them signing in. ## Enterprise roles don’t grant app access Activity across organizations shows each app’s name, organization, release versions, channels and install counts. To open an app, create a release, or publish a patch, a person needs an [organization role](#organization-roles) in the organization that owns it, even if they are an enterprise Owner. This keeps people who manage the account or pay for it, such as IT or accounts payable, from shipping to your users by default. An engineer who is also an enterprise Admin holds both roles and gets both sets of abilities. Enterprise Admins and Owners can still reach any app, because they can add anyone in your enterprise to any of its organizations, themselves included, with any role the organization’s plan offers except Owner. They do it from the **Organizations** tab of the **Enterprise** page: select the organization and click **Add member**. The person is added at once, with no invitation, and the organization’s [audit log](/enterprise/audit-logs/) records it as `org_member.add`. Give these two roles only to people you’d trust with your apps. ## Access report The access report lists everyone who can reach your enterprise’s apps, and how. On the **People** tab of the **Enterprise** page, click **Download access report** to get it as a CSV file. Enterprise Admins and Owners can download it. It has a row for each way a member, guest, or service account reaches your apps: each organization they belong to, with its apps and their role there, and each app they collaborate on. Someone with no access gets one row with those columns empty. Each row also has their enterprise role, how they sign in, and when they last signed in and were last active. Use it for periodic access reviews. ## Deactivate someone Deactivate offboards a person in one step. On the **People** tab of the **Enterprise** page, open the person and click **Deactivate**, or select several people to deactivate them together. Enterprise Admins and Owners can do this, and only an Owner can deactivate an Admin or Billing manager. A deactivated person: * Loses every organization and app in your enterprise. * Is signed out everywhere, and their API keys and invitations are revoked. * Can’t sign in to Shorebird. The account and its history are kept. The **Deactivated** list on the **People** tab shows who was deactivated, and **Reactivate** lets them sign in again. Their sessions, API keys, and any organizations beyond your default organizations don’t come back. Before you deactivate someone, give them another role if they’re an enterprise Owner, and give any organization they own [a new owner](/account/access-and-ownership/#on-the-enterprise-plan). With [SCIM](/enterprise/scim/), your identity provider deactivates people when they leave. ## Guest policy The guest policy sets who outside your domains the organizations in your enterprise may invite. On the **People** tab of the **Enterprise** page, click **Guest policy** in the **Guests** section and choose one: * **No guests.** Only people at your domains can be invited. * **Guests from these domains.** People at your domains and at the domains you list, such as an agency’s. * **Anyone.** Organizations may invite anyone. Guests already in your organizations keep their access under a stricter policy. The console marks them **Outside guest policy**, and you can remove them from the **Guests** section, one at a time or all at once. ## Organization roles Each organization has its own members, each with one of Viewer, Developer, App Manager, Admin or Owner. These roles apply to every app in that organization. See [Member roles](/account/orgs#member-roles) for what each one can do. Organization Admins and Owners manage their organization’s members. They don’t need an enterprise role to do it. ## Who should hold which role Most companies divide the work like this: | Who | Enterprise role | Organization role | | --------------------------------------------- | --------------- | ------------------------------- | | The engineering champion for Shorebird | Owner or Admin | Owner of the app’s organization | | An engineering manager, CTO or contract owner | Owner | None, or Viewer | | Accounts payable or procurement | Billing manager | None | | The rest of the mobile team | Member | Developer or App Manager | * **Owners** control who holds each role, whether your domains must sign in through SSO, and your contracts. The engineering champion can be an Owner when your company doesn’t mind engineers seeing the contract; otherwise make them an Admin and give Owner to a manager. Keep at least two Owners, so the account isn’t stranded when one leaves. * **Admins** handle people day to day: they remove people who leave, manage guests, revoke stray API keys and watch the audit log. * **Billing managers** see billing, invoices and contracts, without access to your people or apps. * **The organization’s Owner** invites the mobile team, sets each person’s organization role, and manages releases and patches. Organization roles are what grant access to apps. If one person does more than one of these jobs, give them each role it needs.