Working With Shared Projects
Shared projects are the day-to-day working surface inside a Business workspace. Once a project lives there, it belongs to the workspace rather than to one person's private account.
Open the right workspace first
Before you work with a shared project, make sure you are in the correct Business workspace. GridGap treats active workspace context seriously. A shared project should be viewed and edited from the matching workspace, not from personal context.
This matters because project access, editing rights, result visibility, and PDF export depend on the current workspace matching the project you are trying to use.
Understand what role you have
In a Business workspace, your role affects what you can do. Owners, admins, and members can normally edit shared projects when the workspace is active. Viewers can review shared projects and results, but they do not have the same editing access.
Owners and admins also manage members. Workspace billing remains owner-only. So if something is missing, check the role before assuming the project itself is broken.
Use the workspace projects area as the team hub
The workspace projects area is the normal starting point for shared work. It shows the shared project list, the current role, member counts, and the import entry point when your role can use it.
This is the right place to open shared projects, create new shared work, and keep track of what belongs to the workspace.
Keep personal and shared work separate
A shared project is not just a personal project seen by other people. It belongs to the workspace. That means the team should treat the workspace copy as the active shared record and avoid mixing it up with a separate personal copy of the same job.
When a project needs collaboration, keep the work moving forward in the workspace version so that the team is looking at one consistent project history.
Watch workspace state as well as role
Shared work also depends on workspace state. If the workspace is inactive or has gone over its seat limit, some functions may be restricted until the owner or admin fixes the workspace status.
So when something feels blocked, the cause may be subscription state or seat limit rather than the project itself.
Use the members and billing areas when needed
Shared project work does not live in isolation. The members area helps you see who can access the workspace and manage invitations. The workspace billing area shows billing state, seat counts, and whether the workspace is operating cleanly.
If collaboration problems appear, these two areas are often the first place to check.
A simple working pattern
The cleanest shared workflow is this. Open the correct workspace, confirm the role, work from the workspace projects area, and keep all team-facing project changes inside the shared copy. Use personal space for private drafts only when they are genuinely meant to stay private.