> ## Documentation Index > Fetch the complete documentation index at: https://docs.parable.work/llms.txt > Use this file to discover all available pages before exploring further. # Workspaces > Understand the Workspace boundary: members, roles, data, Parables, and what access each person has. # Workspaces A Workspace is one organization's home in Parable. It holds that organization's people, Providers and their data, Parables, Ponder Problems, and Powers, and it keeps them apart from every other Workspace. Workspaces give each company a clear boundary around who can see and change its data and apps. Each Workspace has its own address, such as acme.parable.work. One sign-in reaches every Workspace where you are a member. The Switch Workspace menu under the Parable wordmark at the top of the sidebar moves between them. Switching opens the other Workspace at its own address and does not carry the current page across, because Parables, Providers, and people belong to one Workspace. A published Parable can be deployed to other Workspaces, and each destination reads its own data. Deploying never copies data between Workspaces. Access works in layers. Membership decides whether you can enter a Workspace at all. Roles, assigned to each member, carry the permissions that decide what you can do there, such as inviting people, managing Providers, or managing Parables. Inside a Parable, Participant seats and Policies decide more. These layers are separate: Workspace membership is not a Parable seat, a Parable seat does not grant membership, and platform administration is a different scope from Workspace membership. A Power or a Participation Mode never adds access. The server checks each person's current access on every action, so hiding a button protects nothing. Powers are the Workspace's knowledge for Ponder: each one explains an area and brings the tools Ponder uses there. A Power's Tools tab chooses which tools Ponder can use, and a Workspace manager sets whether each tool asks first: Ask for actions that change important state, Never for tools no one should use, and Always only for safe, routine calls. Listing and reading Powers is always available, so Ponder can find the rest. Every tool call runs as the person Ponder is answering, and even Always cannot bypass an operation's own authorization, ownership, state, or revision checks. Workspace managers control sign-in under Protection, Login. Exactly one login method is active at a time: Magic Link, Social Login, OIDC, or SAML. The current method stays active until a replacement is configured and passes its connection test. After compatible SSO is set up, SCIM can add and remove people from the organization's identity provider. The default role under Protection, Login is the starting access for everyone SSO or SCIM brings in and everyone Ponder invites, so a person chooses the least-privileged role; Ponder cannot set it. Roles decide which rows each person reads, so Ponder never chooses or changes anyone's roles: a person does that in People. Inviting, suspending access, and removing a person all change access, and by default Ponder pauses those actions for your approval. Removing someone ends their access to everything in the Workspace. A Workspace API token acts as one person in one Workspace and cannot reach another. Never paste secrets, sign-in links, SCIM tokens, or API tokens into Ponder, tickets, or screenshots. 1. See who is here. Ask Ponder to list the people in the Workspace, filter them by what they can do, or list invitations and where each one stands. 2. See the roles. Ask Ponder for the roles available in this Workspace and who holds each; administrators can rename roles, so read the current list. 3. Invite someone. Give Ponder the email address. Ponder's invitation gives the Workspace's default role; when someone needs other roles, a person invites them from People. A Workspace with no default role refuses Ponder's invitation until a manager sets one. Review the approval card, because accepting the invitation gives that person access. Ponder can resend or cancel an invitation that has not been accepted. 4. Change access. Ask Ponder to suspend or restore a member's access, or remove them. Name the person and the intended result, and approve only when the card matches. To change a member's roles, a person edits them in People. 5. Review sign-in. Ask Ponder to read the Workspace's login policy. To change it, keep the current method active, configure the replacement, test it, activate it, and confirm a second manager can sign in. A healthy Workspace gives every person the least access their work needs, keeps at least two managers able to sign in, uses a deliberate default provisioning role, and keeps secrets out of chat. To check a change, read the member again and confirm their roles or status, confirm the invitation shows the expected state, and have a second manager complete a sign-in after any login change. Related Powers: Participants, Policies, Providers, Publishing. Find each by its title; do not guess stored names. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.