> ## Documentation Index > Fetch the complete documentation index at: https://docs.kinship.io/llms.txt > Use this file to discover all available pages before exploring further. # Public vs Restricted Projects — Reference > Facts and behaviors of public and restricted projects in Kinship: visibility, search behavior, access control, team membership, and management permissions. Use this page to quickly check how **public** and **restricted** projects behave and what they do not do. ## What public and restricted projects are * **Public projects**: Projects visible to all team members (default visibility mode). * **Restricted projects**: Projects marked as confidential, visible only to administrators (or security administrators if enabled) and project team members. *** ## Visibility and access ### Public Projects | Aspect | Behavior | | :------------------------ | :--------------------------------------------------------------------------------------------- | | **Visibility** | Visible to all team members | | **Browse access** | All users can browse to project pages | | **Search results** | Appear in search results for all users | | **Collection assignment** | Collections can be assigned to this project by any user with collection management permissions | | **UI indicator** | No special icon | ### Restricted Projects | Aspect | Behavior | | :------------------------ | :------------------------------------------------------------------------------ | | **Visibility** | Only visible to administrators/security administrators and project team members | | **Browse access** | Only accessible to authorized users | | **Search results** | Content not searchable by users without access | | **Collection assignment** | Collections cannot be assigned to this project by users without access | | **UI indicator** | Blue lock icon next to project name | *** ## Who can view projects ### Public Projects * **All team members** can view public projects and their models * No restrictions on browsing, searching, or accessing content ### Restricted Projects Restricted projects are visible to: 1. **Administrators** (or **Security Administrators** if enabled) * When Security Administrators are enabled, regular Administrators lose access unless they're part of the project team * Security Administrators always have access 2. **Project team members** * Users who have performed at least one **Synchronize with Central** (SwC) from a model in the restricted project * Team membership is automatic based on SwC activity This same logic applies to **Model Sync Rules**: since these rules are path-based, they follow the same file access principles. If a user can't access files at a particular path due to company restrictions, they won't be able to sync with models in that path, and thus won't become project team members. When Security Administrators are enabled, regular Administrators cannot access restricted projects unless they're part of the project team. *** ## What users without access cannot do For restricted projects, users without access cannot: * Browse to the project's page * See the project or any of its models in the Browse Projects or Browse Models pages * See search results from the project in the add-in search box or on the webpage search results * Assign collections to the project *** ## Team membership ### How project team membership works * Team membership for restricted projects is **automatic** * A user is added to a restricted project when they perform a **Synchronize with Central** (SwC) from a model in that project * Once added, the user has ongoing access to the project * Team membership is based on actual work activity, not manual assignment ### Public projects * All team members have access by default * No team membership concept applies *** ## Creating and managing restricted projects ### How to create restricted projects Restricted projects can be created **From the web interface** * An administrator (or security administrator) can **Set as Restricted** from the project page Creating a Restricted Project from the Web Interface * An administrator can also **Make Visible to Team** to change a restricted project back to public Making a Restricted Project Visible to the Team ### Who can change restricted status | Action | Member | Content Manager | Administrator | Security Administrator | | :--------------------------------- | :--------------------------- | :--------------------------- | :----------------------------------------------------- | :--------------------- | | View restricted projects | Only if part of project team | Only if part of project team | Only if part of project team (when Sec Admins enabled) | ✔ | | Change project's restricted status | | | | ✔ | The table above shows permissions when Security Administrators are enabled. If your team doesn't use this role, Administrators have the same permissions as Security Administrators. *** ## Search behavior ### Public Projects * Project content and model content appear in search results for all users * Searchable in both the Revit add-in and web interface * No restrictions on content discovery ### Restricted Projects * Project content and model content are **not searchable** by users without access * **In the Revit add-in**: Non-admin project members will see results from a restricted project when working on that project (i.e., when a model from that project is active in Revit) * If a different model is active in Revit, users won't see results from restricted projects to which they don't have access * **Restricted collections** work the same way: when assigned to a project, members can see that content when the model in that project is active; if they have a different model open, they won't see the result * Search results are filtered based on the active model context and user's project team membership *** ## Model Sync Rules integration Model Sync Rules can automatically create restricted models: * Rules can be configured to automatically add matching models as **restricted** * This creates a new restricted model automatically * Useful for protecting sensitive work based on file location or name patterns Example: A rule matching `*\confidential\*` can automatically create restricted models for any model in a confidential folder. *** ## Security Administrator implications When Security Administrators are enabled: * Regular Administrators lose access to restricted projects unless they're part of the project team * Only Security Administrators can view and manage restricted projects by default * This creates separation between general administration and security-sensitive administration When Security Administrators are **not** enabled: * Administrators have full access to restricted projects * Administrators can view, manage, and change restricted status *** ## UI indicators * **Public projects**: No special icon, appear normally in project lists * **Restricted projects**: Display a **blue lock icon** next to the project name The blue lock icon makes it easy to identify restricted projects at a glance in: * Project browse pages * Project lists * Search results (for users with access) *** ## Quick comparison | Feature | Public Projects | Restricted Projects | | :------------------------ | :--------------------------------- | :--------------------------------------------------- | | **Default visibility** | All team members | Administrators and project team only | | **Searchable by** | All users | Only authorized users | | **UI indicator** | None | Blue lock icon | | **Collection assignment** | Collections can be assigned by all | Collections can only be assigned by authorized users | | **Use case** | Standard firm work | Confidential or sensitive work | *** ## Learn more * [Model Sync Rules](about-model-sync-rules)