> For the complete documentation index, see [llms.txt](https://community-test.logicnets.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://community-test.logicnets.com/release-9/platform-documentation/advanced-topics/version-control/team-group-vs-individual-strict-version-control.md).

# Team (group) vs Individual (strict) Version Control

When you use version control, the system checks out and locks projects at the Workspace/Designer level. However, you can set up your workspace(s) to allow for team control versioning or for stricter individual versioning control.

* **Team Version Control** is also called "group" control, and it is when a group of users are configured to work in the same workspace and a project in that workspace has been entered into version control. Under this setup, each user configured to work in the workspace can check out a project, make changes, and check it in as a new revision, with the following provisos:
  * Any user with local access to the workspace can check out the project.
  * Once a project is checked out, users with local access to the workspace can still edit that project and check in or discard the revision for that project potentially with changes from multiple users, even though it was checked out by another user.

    **Note:** Any user without local access to the original workspace but with access to the project via a shared workspace configuration is NOT able to edit or check out the project until it has been checked in by a user in the original workspace.
* **Individual Version Control** is also called "strict" control, and it is when each user has their OWN workspace and project(s) are shared across workspaces using the Shared Workspace functionality. Under this setup, if a project is accessible by each user via the shared workspace functionality, the following rules apply:
  * Any user with remote-modify rights to the shared workspace can check out the version-controlled project and make edits.
  * No other users can check out the same project UNTIL the first user has checked it in or discarded the revision.

This means that:

1. Under team version control, a revision can contain edits from multiple users in the same workspace.
2. Under individual version control, each revision can only contain edits from a single user via their own workspace.

The decision to use team or individual version control is made by the Workspace/User Administration based on how the workspaces and users are assigned to user groups. It is possible to create a hybrid situation where certain "power users" might work under individual version control and a support team might work under team version control.

#### User Group and Workspace Configuration

* Individual Version Control requires one user group and one workspace for each user, with remote-modify access to a shared workspace with the project(s).
* Team Version Control needs just one user group and workspace for all users. Project(s) can exist in this or a shared workspace.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://community-test.logicnets.com/release-9/platform-documentation/advanced-topics/version-control/team-group-vs-individual-strict-version-control.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.