# Permission Levels## OverviewOpenRails uses a granular permission system to control access to Data Lakes within Projects. Permissions are assigned per-user, per-Data Lake, and per-security level, giving administrators precise control over who can access what data.## Security Classification LevelsOpenRails uses a five-tier security classification system, from least to most restrictive:| Level | Description | Typical Use Cases |
| ---------------- | ----------------------------------- | ----------------------------------------------------- |
| Public | Accessible to all authorized users | General documentation, public FAQs, marketing content |
| Internal | Accessible to internal team members | Internal processes, company policies, team resources |
| Confidential | Restricted to specific users | Customer data, business strategies, internal reports |
| Secret | Highly restricted access | Financial data, legal documents, sensitive contracts |
| Top Secret | Maximum restriction level | Executive communications, M&A data, critical IP |## How Permissions Work### The Permission MatrixPermissions are configured as a matrix where:* Rows = Data Lakes in the project
* Access only Public and Internal content in Data Lake B
* Access Public, Internal, and Confidential in Data Lake C### Permission InheritancePermissions are **additive** within a Data Lake:* Granting "Confidential" does NOT automatically grant "Public" and "Internal"
* Each level must be explicitly granted
* This allows for unusual configurations if needed (e.g., access to Secret but not Internal)### User-Level AssignmentEach user in a Project has their own permission configuration:* User A might have full access to all Data Lakes
* User B might only access specific Data Lakes at lower security levels
* User C might have mixed access across different Data Lakes## Configuring Permissions### Adding a User to a Project1) Navigate to the **Project** → **View Details**
2) Select the **Permissions** tab
3) Click **Add User**
4) Select the user from the dropdown
5) Configure the permission matrix:
- Check boxes to grant access
- Leave unchecked to deny access
6) Click **Save**### Editing User Permissions1) In the Permissions tab, find the user row
2) Click the **settings icon** to expand permissions
3) Modify checkboxes as needed
4) Click **Save**### Removing User Access1) In the Permissions tab, find the user row
2) Click the **trash icon**
3) Confirm removalThe user immediately loses access to all Data Lakes in that Project.## Security Level Guidelines### Public* Information that can be shared broadly
* No competitive or personal data
* Examples: Product documentation, public announcements, general guides### Internal* Information for employees/team members only
* Not for external sharing
* Examples: Internal procedures, team directories, company policies### Confidential* Sensitive business information
* Need-to-know basis
* Examples: Customer lists, pricing strategies, unreleased product info### Secret* Highly sensitive information
* Limited to specific roles
* Examples: Financial reports, legal matters, HR records### Top Secret* Most sensitive information
* Executive and critical personnel only
* Examples: Board communications, acquisition plans, trade secrets## Best Practices### Principle of Least PrivilegeGrant the minimum access necessary for each user's role:* Start with lower security levels
* Add higher levels only when justified
* Review permissions periodically### Role-Based PatternsCreate consistent permission patterns for common roles:| Role | Typical Access |
| ------------------- | -------------------------------------- |
| **General Staff** | Public, Internal |
| **Department Lead** | Public, Internal, Confidential |
| **Manager** | Public, Internal, Confidential, Secret |
| **Executive** | All levels |### Regular Audits* Review permissions quarterly
* Remove access for departed employees immediately
* Verify permissions match current job responsibilities### Documentation* Document why users have elevated access
* Track permission changes
* Maintain an access request process## Permission Scenarios### Scenario 1: New Employee Onboarding1) Add user to relevant Project(s)
2) Grant Public and Internal access to general Data Lakes
3) Add Confidential access only for job-specific Data Lakes
4) Document the access granted### Scenario 2: Role Change1) Review current permissions
2) Remove access no longer needed
3) Add access for new responsibilities
4) Update documentation### Scenario 3: Project Collaboration1) Identify which Data Lakes the collaborator needs
2) Grant minimum necessary security levels
3) Set a review date to reassess access
4) Remove access when collaboration ends## Troubleshooting| Issue | Cause | Solution |
| ---------------------------------- | --------------------- | ------------------------------------------------- |
| User can't see Data Lake | Not added to Project | Add user to Project with appropriate permissions |
| User sees Data Lake but no content | Wrong security level | Grant the security level of the content they need |
| User has too much access | Over-permissioned | Audit and reduce to minimum necessary |
| Permissions not saving | Browser/session issue | Refresh page, try again, check for errors |---**Related:** [Projects](./01-projects.md) | [Data Lakes](./04-data-lakes.md) | [Company Chat](./07-company-chat.md)