Sharing and Collaboration Best Practices

This guide provides proven patterns and security recommendations for managing access control effectively in Catalio.

Security Best Practices

Start Restrictive, Expand as Needed

Principle: Begin with the most restrictive visibility and add access as requirements become clear.

Recommended Approach:

1. Create new resources as Private by default
2. Share with specific teams as the work progresses
3. Move to Shared when collaboration is needed
4. Set to Internal only when the resource is finalized and broadly relevant

Why This Matters:

• Prevents accidental exposure of draft or sensitive content
• Ensures you consciously decide who should have access
• Reduces risk of sharing incomplete or inaccurate information

Review Access Periodically

Principle: Access grants should be reviewed regularly to ensure they remain appropriate.

Review Checklist:

• Are all teams with access still involved with this resource?
• Do team members still need their current permission levels?
• Have any team compositions changed that affect access?
• Is the visibility level still appropriate for the resource’s current state?

Recommended Review Schedule:

Use Teams, Not Individuals

Principle: Grant access to teams rather than tracking individual user access.

Benefits:

• Scalability: New team members automatically get appropriate access
• Maintainability: One change updates access for all team members
• Consistency: All team members have the same access level
• Auditing: Easier to understand who has access and why

Team Organization Tips:

• Create role-based teams (Backend Team, QA Team, Product Team)
• Consider project-specific teams for large initiatives
• Use small, focused teams for sensitive resources

Apply Least Privilege

Principle: Grant only the permissions users need to do their work.

Implementation:

• Default to Viewer access for new team grants
• Upgrade to Editor only when modification is required
• Reserve Owner status for truly responsible parties
• Avoid granting Editor access “just in case”

Permission Decision Tree:

Does the team need to modify this resource?
├── No → Grant Viewer access
└── Yes → Is this team the primary responsible party?
          ├── No → Grant Editor access
          └── Yes → Consider Owner status

Organizing for Effective Collaboration

Team-Based Sharing Patterns

Pattern 1: Development Team Structure

Requirement: "Payment Processing"
├── Payments Team (Owner) - Primary responsibility
├── Backend Team (Editor) - Implementation
├── Security Team (Viewer) - Review and compliance
└── QA Team (Viewer) - Test preparation

Pattern 2: Cross-Functional Collaboration

Process: "Customer Onboarding"
├── Product Team (Owner) - Overall ownership
├── Design Team (Editor) - UX requirements
├── Engineering Team (Editor) - Technical requirements
├── Customer Success (Viewer) - Implementation awareness
└── Marketing (Viewer) - Feature communication

Pattern 3: Review and Approval Workflow

Requirement Lifecycle:
1. Draft (Private) → Author only
2. Review (Shared) → Author + Review Team (Editor)
3. Approved (Internal) → All organization (Viewer), Implementation Team (Editor)

Process Hierarchy Benefits

Leverage Catalio’s resource hierarchy for efficient access management:

Single Point of Control:

Instead of granting access to 10 individual requirements, grant access to the Process:

Process: "Authentication System"
├── REQ-001: OAuth Integration
├── REQ-002: SSO Implementation
├── REQ-003: MFA Support
└── ... (7 more requirements)

Grant Backend Team Editor access to Process → Automatically applies to all requirements

Benefits:

• One access grant covers the entire feature area
• New requirements added to the process inherit access
• Easier to audit and manage access

When to Use Direct Grants Instead:

• When different teams need different access to children
• When some requirements are more sensitive than others
• When temporary access is needed for specific items

Visibility Strategy by Resource State

Audit Trail Awareness

Catalio tracks all access changes. Understanding this helps with:

What’s Tracked

• Who granted access and when
• Who revoked access and when
• Visibility changes
• Ownership transfers

Using Audit Information

• Compliance: Demonstrate access control for regulatory requirements
• Security: Investigate unexpected access patterns
• Management: Understand collaboration history

Access Investigation

When you need to understand why someone has access:

1. Open the sharing modal
2. Check the Who Has Access panel
3. Review all three tabs:
   • Direct: Explicit grants on this resource
   • Inherited: Access from parent resources
   • Organization: Admin and internal visibility access

Organization-Wide Defaults

Default Visibility Settings

Work with your organization admin to set appropriate defaults:

Conservative Default (Recommended for sensitive industries):

• New Requirements: Private
• New Processes: Private
• New Personas: Shared

Collaborative Default (Recommended for open cultures):

• New Requirements: Shared
• New Processes: Internal
• New Personas: Internal

Team Templates

Create standardized teams for common access patterns:

Common Patterns and Anti-Patterns

Patterns to Follow

Pattern: Staged Visibility

1. Create requirement as Private
2. Add immediate team as Editors
3. Add review team as Viewers
4. After approval, change to Internal

Pattern: Feature Team Access

Process: "New Feature X"
├── Feature Team (Owner)
├── Platform Team (Editor) - Cross-cutting concerns
└── Documentation Team (Viewer) - For user docs

Pattern: Sensitive Information Isolation

Requirement: "Security Credentials Handling"
├── Visibility: Private
├── Security Team (Editor)
├── Lead Developer (Viewer)
└── No inherited access (standalone requirement)

Anti-Patterns to Avoid

Anti-Pattern: Over-Sharing

❌ Setting everything to Internal "to be transparent"
   Problem: No access control, sensitive info exposed

✓ Use Shared with explicit grants, move to Internal when appropriate

Anti-Pattern: Individual Grants

❌ Sharing with john@company.com, jane@company.com, bob@company.com...
   Problem: Unmanageable as team changes

✓ Create "Project Alpha Team" and share with the team

Anti-Pattern: Forgotten Access

❌ Granting access during a project, never reviewing after
   Problem: Accumulates inappropriate access over time

✓ Schedule periodic access reviews

Anti-Pattern: Everyone is Editor

❌ "Just give everyone Editor access to be safe"
   Problem: No meaningful access control

✓ Default to Viewer, grant Editor only when needed

Anti-Pattern: Ignoring Inheritance

❌ Wondering why team X can see this requirement
   Problem: Not checking inherited access

✓ Always check the Inherited tab in Who Has Access

FAQ

Can I share with a specific person instead of a team?

Catalio shares with teams for scalability and maintainability. To share with an individual:

1. Check if they belong to an appropriate existing team
2. If not, ask your admin about creating a small team
3. Or use organization-level discussions for one-off collaboration

What happens when I change visibility to Private?

• Teams with explicit grants keep their access
• Organization members without explicit grants lose read access
• Content is no longer searchable by unprivileged users

Can I undo an ownership transfer?

Only the new owner can transfer ownership back. If you accidentally transferred ownership:

1. Contact the new owner to transfer back
2. Or contact your organization admin for assistance

Why can someone still see my private resource?

Check for:

1. Organization Admin status - Admins see everything
2. Explicit team grants - Check the Direct tab
3. Inherited access - Check the Inherited tab for parent resources

How do I know who can see my resources?

Use the “Who Has Access” panel in the sharing modal. It shows all three access sources:

• Direct grants
• Inherited from parents
• Organization-level access

What’s the difference between Shared and Internal?

Can I prevent organization admins from accessing my resource?

No. Organization admins have full access to all resources by design. This ensures:

• Business continuity if resource owners leave
• Compliance and audit capabilities
• Emergency access when needed

If you have content that should be restricted from admins, discuss data handling policies with your organization leadership.

Summary Checklist

Before Creating a Resource

• Determine who needs access
• Choose appropriate starting visibility (usually Private)
• Identify which teams to share with

When Sharing

• Grant minimum necessary permissions
• Use teams, not individuals
• Consider using hierarchy (Process) for multiple related items

Ongoing Maintenance

• Review access monthly for active resources
• Remove team access when no longer needed
• Update visibility as resource state changes
• Check inherited access when troubleshooting

Before Archiving

• Review current access grants
• Consider changing visibility to Private
• Document why access was granted (in comments if needed)

What’s Next?

• Sharing Overview - Understanding visibility levels
• Managing Access - Step-by-step sharing guide
• Permission Levels - Understanding viewer, editor, and owner roles

Need help? Contact support@catalio.ai or use the AI assistant in the application for guidance on sharing best practices.