Skip to main content

​
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. For designing roles, see Members & 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:
  • 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).
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.

​
Provisioning people

Pick the method by what you know about each person and how many there are.

​
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. 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.

​
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.

​
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. 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.

​
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.

​
Who may grant what

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: 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 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.
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.
  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).
  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

Inviting People

Invitations, invite links and creating accounts, step by step

Members & Roles

Create roles and decide what each one can do

Identities

The people directory your team members appear in

User Authentication

Sign-in methods for your apps