Skip to main content

​
Overview

Projects maintain strict data isolation to ensure security, privacy, and organization. Each project operates as an independent workspace with its own data that cannot be accessed from other projects. Data Separation

​
Why Data Separation Matters

Data separation is critical for:
BenefitDescription
SecuritySensitive contract and financial data stays within its project
PrivacyDifferent clients or artists can’t see each other’s data
OrganizationClear boundaries make data management easier
ComplianceMeet regulatory requirements for data isolation
Access ControlGrant access to specific projects without exposing others

​
Fully Isolated Data

The following data types exist only within their project and cannot be accessed from other projects:
Data TypeIsolation LevelDescription
ContractsCompleteContracts exist only within the project where they were uploaded
Extracted DataCompleteAI-extracted contract terms are project-bound
CatalogCompleteRecordings and compositions are project-specific
StatementsCompleteFinancial data and royalty statements are project-bound
InsightsCompleteAnalytics and reports are calculated per project
Custom ViewsCompleteView configurations are project-specific
TagsCompleteDocument tags are project-scoped
CRM DataCompleteEntities, artists, and relations are project-specific
Agent ConfigurationsCompleteAI agent settings are per-project

​
Shared Across Organization

Some data is shared at the organization level:
Data TypeScopeDescription
Team MembersOrganization-wideMembers are added to organization, then given project access
Security SettingsOrganization-wideSSO and audit log settings apply to all projects
Organization Entities ViewOrganization-wideAggregated view of entities across projects (read-only)

​
Cross-Project Considerations

​
Entities Across Projects

While entities are created within projects, you can view entities across all projects from the Organization Entities page:
  • Organization view shows entities from all projects
  • Editing must be done within the specific project
  • Linking entities that represent the same company helps maintain consistency

​
Team Member Access

Organization members must be explicitly granted access to each project: 
Organization: Your Company
├── Member: Alice (Admin)
│   ├── Project A: Full Access
│   ├── Project B: Full Access
│   └── Project C: No Access
├── Member: Bob (Member)
│   ├── Project A: Editor
│   ├── Project B: No Access
│   └── Project C: Viewer
Being a member of the organization doesn’t automatically grant access to all projects.

​
External Projects

Users can be invited to specific projects without being full organization members:
  • These appear as “External Projects” on their dashboard
  • They only see the specific project they were invited to
  • They don’t see other organization projects or settings

​
Data Flow Between Projects

​
What CAN’T Cross Projects

ActionAllowed?
Copy contracts between projectsNo
Share catalog items between projectsNo
Reference statements across projectsNo
Use tags from another projectNo
Apply views from another projectNo

​
What CAN Cross Projects

ActionAllowed?
View entities across projects (read-only)Yes
Same user accessing multiple projectsYes
Organization-wide security settingsYes

​
Practical Examples

​
Label with Multiple Artists

Organization: Your Label
├── Project: Artist A
│   ├── Contracts: Artist A's deals only
│   ├── Catalog: Artist A's recordings only
│   └── Statements: Artist A's royalties only
├── Project: Artist B
│   ├── Contracts: Artist B's deals only
│   ├── Catalog: Artist B's recordings only
│   └── Statements: Artist B's royalties only
└── Project: Artist C
    ├── Contracts: Artist C's deals only
    ├── Catalog: Artist C's recordings only
    └── Statements: Artist C's royalties only

Result: Each artist's data is completely separate

​
Publisher with Multiple Catalogs

Organization: Your Publishing
├── Project: Pop Catalog
│   └── All pop music contracts, compositions, statements
├── Project: Rock Catalog
│   └── All rock music contracts, compositions, statements
└── Project: Admin Catalog
    └── Third-party administered works

Result: Each catalog operates independently

​
Management Company with Multiple Clients

Organization: Management Co
├── Project: Client A
│   └── Client A can only see their data
├── Project: Client B
│   └── Client B can only see their data
└── Project: Client C
    └── Client C can only see their data

Result: Clients cannot see each other's information

​
Security Implications

​
Access Control

ScenarioResult
User has access to Project A onlyCannot see Project B data
Admin removes user from projectImmediate loss of access
User leaves organizationLoses access to all projects

​
Data Breaches

If one project is compromised:
  • Other projects remain secure
  • Organization-level data may be affected
  • Immediate action: revoke access and audit

​
Best Practices

Consider what data should be separate before creating projects. It’s easier to keep things separate than to split them later.
When the same company appears in multiple projects, use consistent naming to make the organization entities view useful.
Only give users access to the projects they need for their work.
Periodically audit who has access to each project and remove unnecessary permissions.
If two catalogs frequently reference the same entities or contracts, consider whether they should be in the same project.

Projects Overview

Understanding projects in your organization.

Organization Entities

View entities across all projects.

Team Members

Managing member access.

Security Settings

Organization-wide security configuration.