Members and access
Learn how workspace membership and Group access work together in Giga.
Access in Giga happens at more than one level.
A person first needs to be a member of the workspace. From there, shared Groups determine which team resources they can access.
Workspace membership vs Group access
| Layer | What it controls |
|---|---|
| Workspace membership | Whether someone belongs to the Giga workspace at all |
| Workspace role | Their workspace-level role, such as owner, admin, or member |
| Group membership | Which shared Groups and the resources inside them they can access |
Being in the workspace does not automatically mean someone belongs to every shared Group.
Workspace membership comes first
A teammate must exist in the workspace before an admin can give them access to a shared Group.
Inviting a teammate
Workspace admins can add a person to the workspace by email.
When someone is added, Giga can provision their default workspace setup, including their personal/private area.
Add them to the workspace
Invite the teammate by email and assign the appropriate workspace role.
Find the shared Group they need
Choose the Group that already contains the Tracks and resources relevant to their work.
Grant Group access
An admin can add the existing workspace member to that shared Group.
Work from the same shared context
The teammate can then access the resources available within that Group according to their permissions.
Workspace roles
The current workspace membership model includes:
- Owner
- Admin
- Member
Some actions are restricted by role. For example, inviting a new workspace member or adding an existing member to a shared Group is an admin-level operation.
We cover the broader admin model separately in Teams & Admin.
Permissions are checked live
Giga should verify a person’s current role and access before making permission-sensitive changes.
What Group access can expose
A shared Group can contain or scope several kinds of resources:
Tracks
Ongoing work, context, files, and memory that live inside the Group.
Agents
Reusable Agents available within the Group’s access scope.
Files
Shared work product stored with Tracks or within the Group.
Credentials and Connections
Connected access that may be available to members of the relevant Group.
Because Group membership affects access to these resources, it should be managed deliberately.
Private Groups are different
Each member has a private Group for their own work.
That private Group is intended for personal Tracks and other resources that should not automatically be shared with teammates.
You do not add other teammates to someone else’s private Group as a normal sharing pattern. Shared collaboration belongs in a shared Group.
Learn about personal vs shared work →
A simple example
Imagine a new teammate joins the Customer Success team.
Workspace membership
They are invited into the Giga workspace first.
Customer Success Group
An admin gives them access to the shared Group used by that team.
Customer Tracks
They can work from the same customer-specific Tracks available in that Group.
Shared resources
They can also use other resources available within that Group’s permission scope.
The result is a shared working environment without giving every workspace member access to every team’s work.
Removing someone from the workspace
Removing a member from the workspace is a separate administrative action.
In the current Giga model, removing a member soft-archives their membership rather than deleting their data. Owners cannot be removed through this operation.
Because this changes someone’s access, Giga should confirm before carrying it out.
Access changes deserve confirmation
Adding or removing access can affect what company information someone can reach. Giga should verify the current workspace state and confirm consequential changes before acting.
Image placeholder
Diagram showing Workspace → Shared Groups → Tracks and shared resources, with different members accessing different Groups.