People and permissions
Invite someone to your workspace when they are part of the team. Share a single project when they only need to work on that app. These choices give different access, so start with the scope of the work you want to share.
People manages workspace membership. A project’s Share dialog manages access to that project. Neither is the same as publishing your app for visitors.
Team invitations, role management, and member credit limits require an active Pro or Business subscription. Room requires Business. Your role must also permit the action: upgrading a plan does not grant administrative access. See Credits and usage.
Open People
Go to Workspace settings → People. The list lets you find members and pending invitations, see roles, and review credit usage. Use search and the role filter to find a person; use the Invitations, Collaborators, and Requests tabs to focus on a particular kind of access.
Available actions depend on your role. Workspace owners and admins can manage the team. People with less access see the controls available to them. External project collaborators do not receive the full workspace member directory.
Roles and permissions
Your workspace role and your project role answer different questions.
Workspace owners and admins have administrative access to workspace projects. A workspace Viewer remains read-only even if a project invitation would otherwise grant editing rights.
In a project’s Share dialog, the access choices are:
The Share dialog only offers access you are allowed to grant. For example, a project Viewer can grant or remove Viewer access; that does not let them invite an Editor or change the app.
Publishing has an additional workspace rule. A project Editor may be able to build while being unable to publish, update the public URL, or manage domains. See Privacy and security settings.
Invite a teammate to the workspace
- Open Workspace settings → People.
- Choose Invite members.
- Enter the person’s email address and choose the appropriate role.
- Review any confirmation for elevated access, then send the invitation.
Pending invitations appear separately from active members. Review the invitation’s expiry and revoke it if it is no longer needed. If an invitation has expired, send a new one.
Use Invite link when a shared invitation is appropriate. Check the role before copying the link. Anyone who receives a valid invitation link may be able to use it, so share it only with the intended people. Rotating or revoking the link changes whether the old link can be used.
Workspace policies can limit invitations or invite links. If a control is unavailable, ask a workspace owner or admin to review the relevant setting.
Share one project
Open the project and choose Share. Enter the person’s email, select Can view, Can edit, or Admin from the available choices, and send the invitation.
Use Can view for someone reviewing progress, Can edit for someone building with you, and Admin only when the person should manage the project’s people and access.
Someone outside the workspace can receive access as an external collaborator. Their access applies to the shared project; it does not make them a workspace administrator. Workspace policies may block external collaboration or cap the role you can offer.
The dialog lists people with project access and pending invitations. Review both before changing access. Removing an explicit project invitation may not remove access someone still has through workspace membership.
General access
Project settings also include General access, which controls how workspace members can access that project. Check it together with individual invitations. A project shared with the workspace can still be reachable through that shared access after you remove one person’s explicit grant.
Choosing restricted project access inside a team workspace requires Business. Choose access based on the audience you intend. This setting controls the project in Mythos, not who can sign in to the app you build.
Work together in Room
Room is the project’s space for human conversation. Use it to discuss a design, share context, and coordinate who is making the next change.
Posting a message to a teammate in Room is different from sending a Build request to Mythos. Keep the change you want Mythos to implement in the project composer. A decision discussed in Room does not automatically change code, Knowledge, or the published site.
Project access and conversation access still matter. A preview link does not make its recipient a Room participant or give them editing rights.
Project invitations, preview links, and Publish
Use the right sharing action for the outcome:
Review what a link exposes before sending it. A published app has its own visitor experience; its authentication and data permissions are separate from Mythos workspace membership.
Review usage and access
People shows credit usage and supports monthly Build-credit limits. An individual limit overrides the workspace default for that member. Use Set credit limit from the person’s menu when you need a specific allowance, and review the displayed value before saving.
A person working on a shared project uses that project’s workspace credits. Their personal balance is not a substitute for the workspace’s available balance and permissions.
You can export the member list as CSV where that action is available. Use the list and user insights to review who still needs access, especially before removing a teammate.
Change or remove access
Use the role control or member menu in People to adjust workspace access. Owner-level and billing ownership changes require the corresponding authority; an admin role is not interchangeable with ownership.
For a project-only change, use its Share dialog instead. Revoke an unused invitation, remove the explicit grant, or adjust General access as appropriate.
Removing access is not a request to delete the person’s work or unpublish an app. Review the confirmation and any remaining workspace or project grants before assuming the person has no access left.
If someone cannot open a project, first check the account they used to sign in, the invitation, their workspace membership, and any connected-tool access the project requires. For an action that is unavailable inside the project, compare their role with the workspace’s relevant restriction before sending another invitation.