> ## Documentation Index > Fetch the complete documentation index at: https://docs.stardeck.ai/llms.txt > Use this file to discover all available pages before exploring further. # Team management for large organizations > How team membership works end to end, how to add hundreds of staff, and how a deployed app should handle member management. ## Overview This guide is for organization admins, and for anyone building an app with Starcat Developer, who need to run a large team: hundreds of staff, several locations, and a mix of office staff and frontline workers. It explains who is who, the ways to add people, how access is granted, and what a deployed app should and shouldn't do about membership. For the step-by-step screens, see [Inviting People](/inviting-people). For designing roles, see [Members & Roles](/members-and-roles). *** ## The model Stardeck keeps membership in one place, the organization, and every app reads from it. There are four kinds of record to keep apart: | Who | Signs in to | Managed under | | - | - | - | | **Team member** | The Stardeck dashboard and the apps their role allows | Organization **Settings → Team Members** | | **App-only team member** | Only the apps assigned to them, no dashboard | **Settings → Team Members**, then **App access** on their account | | **App user** | One deployed app, never Stardeck | That app's **Settings → App Users** | | **Person in the directory** | Nothing. It's a profile, not a login | [**Identities**](/identities) | * A **team member** holds one **organization role**. The role's access level decides whether they reach the dashboard (**Team**) or only their assigned apps (**App-only**). * An **app-only team member** is still a member of your organization. Use it for staff such as cashiers, drivers and kitchen crews who use your apps but never build or configure anything. * An **app user** belongs to one app and holds an **app role** in it. Use it for customers and other outside users. * Every team member is also a **person in the directory**, linked to their login. Their name and email follow their account (see [Team members in the directory](/identities#team-members-in-the-directory)). Inside an app, a team member's permissions come from the app's **Team Member Permissions** setting. By default that is the app permissions you granted their organization role for that app. You can also give a member a specific app role on one app from their **App access** section. See [How access is determined](/members-and-roles#how-access-is-determined). *** ## Provisioning people Pick the method by what you know about each person and how many there are. | Method | Use when | Who can do it | | - | - | - | | **Email invitation** | You have a working email for one person | Admins | | **Bulk invite** | You have working emails for many people | Admins | | **Team invite link** | You don't know their emails, or want people to ask to join | Members with **Invite Team Members** (`members:invite`) | | **Create accounts** | Staff don't use email, or you want to hand out logins yourself | Admins | | **Claim link for app-only staff** | Frontline staff should sign in (for example with LINE) and land in one app | People who can edit the app | ### Email invitation and bulk invite From **Settings → Team Members**, enter an email and pick a role, or click **Bulk invite** to paste a list or upload a CSV. Each person gets an email. Whoever opens the invitation link and signs in joins, whichever email or sign-in method they use, and each invitation admits one person. See [Inviting a team member](/inviting-people#inviting-a-team-member). ### Team invite links A team invite link is a shareable URL that anyone holding it can use to request access or join. You set the role, a use limit and an expiry, and you can require approval so each request waits for an admin. Links can't grant the Admin role. See [Team invite links](/inviting-people#team-invite-links). ### Creating accounts directly **Create accounts** makes logins for people who have none. Type a list, or upload a CSV or Excel file of up to 1,000 rows. For team members, each row can carry its own `role`, `app` and `app_role`, so one file can place 500 people into the right roles and apps. Passwords are generated by default and shown once, with a credentials download. These accounts are **organization-managed**: your admins can edit their name, email and picture and reset their password, and the account can't join any other organization. If a new team member is already in your people directory (for example a staff profile created before they had a login), you can tie the new login to that person instead of creating a second one. This needs the **Govern Identities** (`identities:govern`) permission. See [Creating accounts directly](/inviting-people#creating-accounts-directly). ### Importing a staff list in an app, then creating logins Many organizations keep their staff list in a spreadsheet, and the first thing they do in a new app is import it: names, emails, locations and jobs. Do this in two steps. 1. **The app imports the list as people.** For each row, the app finds or creates the person in your people directory by their email, and saves its own staff row (location, station, job) against that person. Nobody gets a login yet, and importing the same file again finds the same people instead of adding copies. Ask Starcat Developer for a staff import screen and it builds it this way. 2. **An admin creates the logins.** The app offers a file for **Create accounts** with one row per imported person: `email`, `first_name`, `last_name`, `role`, `app`, `app_role` and `identity`, where `identity` is the person's id. Upload it under **Team Members → Create accounts**. Each new login is added to its person, so the staff rows the app already holds now belong to someone who can sign in. Step 2 needs the **Govern Identities** (`identities:govern`) permission, because the file names existing people. Create accounts skips anyone who already has a team login. A row without an email can't get an account this way; leave that person in the directory until you have one. ### Claim links for app-only staff On an app's **Settings → App Users** tab, **App-only team members** creates a claim link for an app-only role. Staff who open it sign in, join your organization with that role, and land in that app with no dashboard access. Create the app-only role first under **Roles & Permissions**. *** ## Giving access ### Organization roles Each team member has one organization role. Built-in roles are **Admin**, **Member**, **Viewer** and **External Viewer**, and you can add your own. Anyone who joins without a chosen role gets your **Role for new members** (Member unless you change it). See [Organization roles](/members-and-roles#organization-roles). ### App-only roles and app access Create an **App-only** role for each frontline job. A member with an app-only role reaches only the apps listed in their **App access**, each with an app role. Open a member's row, then use **App access** at the bottom of the account dialog. Members with a **Team** role can also be given a private app, or a different app role, from the same section. ### Bulk actions on the Members table Admins can tick members in the table and act on all of them at once: * **Set role** changes everyone's organization role, or sets **No role**. * **Add to app** assigns one app and an app role (or the app's default role). * **Remove** removes them from the organization after a confirmation. Each change runs through the same checks as the single-member controls. Members that fail stay selected with the reason shown, so you can retry them. Details are in [Acting on several members at once](/members-and-roles#acting-on-several-members-at-once). ### Who may grant what | Action | Needs | | - | - | | Send email invitations, create accounts, remove members | The **Admin** role | | Change a member's organization role, or assign apps and app roles | **Manage Roles & Permissions** (`roles:manage`) | | Create and revoke team invite links, approve or reject requests | **Invite Team Members** (`members:invite`) | | Invite links that assign apps, or grant an app-only role | `members:invite` and `roles:manage` | | Tie a new login to an existing person | `identities:govern` | Keep the Admin role to a few people. Give location managers a role with `members:invite` so they can hand out approval-required links for their staff without being able to change roles. *** ## Managing members inside a deployed app Membership stays in Stardeck. An app should do one of two things. **Link to Stardeck settings (the default).** Put a link to **Settings → Team Members** or **Settings → Roles & Permissions** in the screens your team members use. Stardeck handles sign-in and permission checks on its side. Starcat Developer uses this pattern unless you ask for more. **Embed team management through the server-side API.** When inviting and re-assigning roles is part of the app's daily workflow, the app can call Stardeck's team-management API from its server. It can list team members and organization roles, invite a team member (with the default role or a chosen one), and change a member's organization role. Removing members, assigning apps and creating accounts stay in Stardeck settings. On every call, Stardeck identifies the actual signed-in team member from their session and checks their current permissions: | Operation | Needs | | - | - | | Invite with the default role | `members:invite` | | List team members and organization roles | `roles:manage` | | Invite with a chosen role | `members:invite` and `roles:manage` | | Change a member's organization role | `roles:manage` | App users and app-only team members are refused. Hiding a button in the app is a convenience, not the security boundary. An app should never: * create logins itself, or keep its own usernames and passwords for staff; * keep its own membership or roles table as the record of who is on the team; * grant or change roles without going through Stardeck. An app can still store its own data about people, such as shift assignments or which location a person works at. Key that data to the person or login Stardeck gives the app, so it follows the member through name and email changes. *** ## Lifecycle **Leaving.** A member can leave from **Settings → Danger Zone → Leave Organization**. The last admin can't leave. Leaving removes their organization role and all app assignments. **Removing.** Admins remove a member from their row or with the **Remove** bulk action. You can't remove yourself. A removed member loses the dashboard and every app, and their app assignments are deleted. **Rejoining.** When the same login rejoins, they get the same person in the directory back, with its history. Their old app assignments are not restored, so assign apps again. **Managed accounts.** Removing an organization-managed member deletes the account, and they can't sign in again. The confirmation says so and names each managed account. Deleting the organization deletes all of its managed accounts. **Password resets.** For a managed account, an admin opens **Edit account** and types a new password or clicks **Generate password**. Setting a password signs the person out of their other sessions. People who signed up themselves reset their own password. *** ## Audit and security * Stardeck records account creation, app assignments made during creation, ties to existing people, and every edit to a managed account (which fields changed and who changed them) in its audit log. [Merging people](/identities#merge) is audited too. * Generated passwords are shown once, in the results and the credentials download. Stardeck doesn't show them again. If one is lost, set a new one from **Edit account**. * A managed account belongs to one organization. It can't join or create another one. * Invite link URLs are shown once when created. Revoke a leaked link; people who already joined keep their access until you remove them. *** ## Recommended setup for a large organization For example, 500 staff across 10 locations, most of them frontline: 1. **Design roles first.** One App-only role per frontline job (Cashier, Driver, Kitchen) and a few Team roles for office staff and managers. Grant each role the app permissions it needs under [App permissions](/members-and-roles#app-permissions-the-bridge-to-your-apps). 2. **Set the Role for new members** to your least-privileged role. 3. **Limit Admin** to two or three people. Give location managers `members:invite` without `roles:manage`. 4. **Load existing staff with Create accounts.** Download the CSV template, fill in `role`, `app` and `app_role` per person, and upload in files of up to 1,000 rows. Store the credentials download securely and hand each person their login. If an app already imported your staff list, upload the file the app gives you instead, so each login joins the person the app created (see [Importing a staff list in an app](#importing-a-staff-list-in-an-app-then-creating-logins)). 5. **Use Bulk invite** for office staff who have reliable email. 6. **For ongoing hiring**, create one approval-required team invite link per location with a use limit and a short expiry, and have managers approve requests under **Pending approvals**. 7. **In your apps**, link to Stardeck settings for membership. Ask Starcat Developer for an embedded screen only if managers invite people from inside the app every day. 8. **Review regularly.** Use the Members table's bulk actions to move people between roles and to remove leavers. *** ## Next steps Invitations, invite links and creating accounts, step by step Create roles and decide what each one can do The people directory your team members appear in Sign-in methods for your apps This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.