How We Designed Workspace Connect for Cross-Team Collaboration

TL;DR

Workspace Connect allows organizations to share projects across separate YouViCo workspaces while maintaining data isolation and fine-grained permissions. Architecture uses cross-tenant references, shared project views with permission filters, and audit logging. Key challenge: allowing read-only or collaborative access to projects without exposing sensitive organization data. Solution: shared project tokens, role-based access control per project, and organization-level veto permissions.

The Problem: Siloed Teams

Two creative teams at different companies (agency and brand) both need to review the same campaign video. Today, they use separate YouViCo workspaces. Agency has one workspace, brand has another. This creates friction:

• Agency uploads video to their workspace
• Brand can’t see it in their workspace
• Agency exports video, brand uploads to their workspace
• Now there are two copies
• Edits in one don’t sync to other

Solution: Workspace Connect allows cross-workspace sharing while keeping each team’s data isolated.

Architecture: Multi-Tenant with Bridges

YouViCo’s core model is workspace-scoped: every project, comment, and user belongs to exactly one workspace (organization). Workspace Connect bridges this with:

Organization A Workspace         Organization B Workspace
┌─────────────────────┐         ┌─────────────────────┐
│ Project "Campaign"  │         │ Project View of     │
│ (Owner)             │         │ "Campaign"          │
│                     │         │ (Read-only access)  │
└────────┬────────────┘         └─────────────────────┘
         │ Shared Token          │
         └──────────────────────┘
              (Cross-workspace link)

The key insight: not moving data, just creating cross-workspace references with permission controls.

Token-Based Sharing

When Organization A wants to share a project with Organization B, they generate a Workspace Connect token:

interface WorkspaceConnectToken {
  id: string;
  sourceWorkspaceId: string;
  sourceProjectId: string;
  targetWorkspaceId: string;
  
  permissions: Permission[];  // ['view', 'comment', 'edit']
  expiresAt: Date;
  
  // Audit
  createdBy: string;
  createdAt: Date;
}

class WorkspaceConnectService {
  async generateToken(
    projectId: string,
    targetWorkspaceId: string,
    permissions: Permission[]
  ): Promise<string> {
    const token = {
      id: uuid(),
      sourceWorkspaceId: currentWorkspace.id,
      sourceProjectId: projectId,
      targetWorkspaceId,
      permissions,
      expiresAt: addDays(now(), 90),
      createdBy: currentUser.id,
      createdAt: now()
    };
    
    await db.workspaceConnectTokens.insert(token);
    
    return token.id;
  }
}

Organization B receives the token and can now view the project within their own workspace.

Permission Enforcement

When Organization B accesses the shared project, permission checks happen at two levels:

Level 1: Organization-Level Veto

• Organization A can revoke the token anytime
• Token can expire
• Organization B can decline/revoke access

Level 2: Resource-Level Permissions

• If token grants ‘view’, user can only view
• If token grants ‘comment’, user can comment but not edit
• Comments from Organization B are visible to Organization A

class SharedProjectService {
  async getProject(projectId: string, userId: string) {
    // First: is this a shared project?
    const sharedProject = await db.sharedProjects.get({
      projectId,
      targetWorkspaceId: currentWorkspace.id
    });
    
    if (!sharedProject) {
      // Not shared, use normal access control
      return this.getProjectInternal(projectId, userId);
    }
    
    // This is a shared project
    const token = await db.workspaceConnectTokens.get(sharedProject.tokenId);
    
    // Check 1: Token still valid?
    if (token.expiresAt < now()) {
      throw new Error('Shared project access expired');
    }
    
    // Check 2: Token revoked?
    if (token.status === 'revoked') {
      throw new Error('Shared project access revoked');
    }
    
    // Check 3: User in target workspace?
    const userWorkspace = await db.users.getWorkspace(userId);
    if (userWorkspace.id !== token.targetWorkspaceId) {
      throw new Error('User not in target workspace');
    }
    
    // All checks passed - return project with permission filters
    const project = await this.getProjectInternal(projectId, userId);
    
    // Apply permission filters
    return {
      ...project,
      canEdit: token.permissions.includes('edit'),
      canComment: token.permissions.includes('comment'),
      canDelete: false  // Never allow delete on shared projects
    };
  }
}

Handling Cross-Workspace Comments

When a user from Organization B comments on a shared project, the comment needs to:

1. Be visible to both organizations
2. Attribute to the correct user
3. Include audit trail (which workspace, which token)

class CommentService {
  async createComment(
    projectId: string,
    frameNumber: number,
    text: string,
    userId: string
  ) {
    // Get the shared project relationship
    const sharedProject = await this.getSharedProjectIfAccessible(projectId, userId);
    
    if (sharedProject) {
      // User is from a different workspace
      const comment = {
        id: uuid(),
        projectId,
        frameNumber,
        text,
        authorId: userId,
        authorWorkspaceId: sharedProject.targetWorkspaceId,
        sourceWorkspaceId: sharedProject.sourceWorkspaceId,
        isFromSharedWorkspace: true,
        sharedViaTokenId: sharedProject.tokenId,
        createdAt: now()
      };
      
      await db.comments.insert(comment);
      
      // Audit log
      await auditLog('shared_comment_created', {
        projectId,
        authorWorkspaceId: sharedProject.targetWorkspaceId,
        tokenId: sharedProject.tokenId
      });
    } else {
      // Normal comment from same workspace
      const comment = { /* ... */ };
      await db.comments.insert(comment);
    }
  }
}

Data Isolation: What Stays Private

When Organization A shares a project with Organization B:

Visible:

• Project name, description
• Video files and frames
• Comments (on shared project only)
• Metadata (duration, frame rate)

Hidden:

• Other projects in Organization A
• Organization A’s team members
• Organization A’s billing info
• Comments on non-shared projects
• Analytics/performance data

This is enforced at the database query level. Queries for shared projects explicitly filter out sensitive data.

Revoking Access

Organization A can revoke access instantly:

async revokeAccess(tokenId: string) {
  const token = await db.workspaceConnectTokens.get(tokenId);
  
  // Mark token as revoked
  await db.workspaceConnectTokens.update(tokenId, {
    status: 'revoked',
    revokedAt: now(),
    revokedBy: currentUser.id
  });
  
  // Audit log
  await auditLog('workspace_connect_revoked', {
    tokenId,
    sourceWorkspaceId: token.sourceWorkspaceId,
    targetWorkspaceId: token.targetWorkspaceId,
    revokedAt: now()
  });
  
  // Optional: notify Organization B
  await notificationService.send(
    targetWorkspaceId,
    'Access to project revoked'
  );
}

From that moment, Organization B loses access. Revocation is instant (checked on every request).

Audit Trail

Every cross-workspace action is logged:

SELECT action, source_workspace, target_workspace, action_time
FROM audit_log
WHERE action LIKE 'shared_%'
ORDER BY action_time DESC;

-- Output:
shared_comment_created   Org A   Org B   2026-03-28 14:23:15
shared_project_accessed  Org B   Org A   2026-03-28 14:22:45
workspace_connect_token_generated  Org A   Org B   2026-03-28 14:20:00

This provides full visibility into who accessed what across workspace boundaries.

Lessons Learned

1. Token-based sharing is simpler than trying to federate authentication.

2. Permission enforcement at multiple levels (organization, resource) prevents accidents.

3. Audit logging is essential for enterprise security. Customers want to know exactly who accessed their data.

4. Revocation must be instant, not eventual. Users expect immediate access removal.

5. Don’t over-expose data. Just because you can share doesn’t mean you should expose everything.

Workspace Connect transformed YouViCo from single-organization tool to collaborative platform. Cross-company workflows increased by 5x after launch.