Skip to main content
This guide is designed for Enterprise customers planning their Relevance AI deployment. These best practices help you scale efficiently and maintain governance as your AI workforce grows.
A well-planned organizational structure is critical for Enterprise success with Relevance AI. The right structure makes it easier to manage permissions, track usage, maintain governance, and scale your AI workforce as your team grows.

​
Understanding the hierarchy

Relevance AI uses a three-level hierarchy for organizing resources:

Organization

The top-level container for your entire company. All users, projects, and assets belong to one organization.Key characteristics:
  • One organization per company
  • Organization-level billing and credits
  • Organization-level SSO and security settings
  • Organization-level admins manage everything

Projects

Containers for related agents, tools, knowledge bases, and workforces. Projects are the primary way to organize work and control access.Key characteristics:
  • Multiple projects per organization
  • Project-level permissions and access control
  • Project-level usage tracking and limits
  • Project-level integrations and API keys

Assets

Individual agents, tools, knowledge bases, and workforces. Assets are the building blocks of your AI workforce.Key characteristics:
  • Assets belong to one project
  • Asset-level permissions for granular control
  • Assets can be shared across projects (with proper permissions)
  • Assets can be organized into folders within projects

​
Project organization strategies

There are three main strategies for organizing projects. Most organizations use a combination of these approaches.
  • By Team
  • By Use Case
  • By Environment

​
Organize by Team or Department

Organize projects around your organizational structure (teams, departments, or business units).Best for: Companies with distinct teams that work independentlyExample structure:
Organization: Acme Corp
├── Project: Marketing Team
├── Project: Sales Team
├── Project: Customer Support
├── Project: Product Team
├── Project: Finance & Operations
└── Project: Executive Team
Advantages:
  • Aligns with existing organizational structure
  • Easy to assign permissions based on team membership
  • Clear ownership and accountability
  • Simple usage tracking per team
Considerations:
  • May lead to duplicate agents across teams
  • Harder to share resources across teams
  • Can create silos if not managed carefully
When to use:
  • You have 3+ distinct teams using Relevance AI
  • Teams work independently with different use cases
  • You want to track usage and costs per team
  • Teams need different integration access or security policies

​
Structure by company size

Choose your team size to see recommended structures and best practices:
  • Small (5-20)
  • Medium (20-100)
  • Large (100+)

​
Small Teams (5-20 users)

Recommended structure: Simple, minimal projects
Organization: Acme Corp
├── Project: Production
├── Project: Development
└── Project: Sandbox
Key recommendations:Start simple with 2-3 projects. Use folders within projects to organize assets. Assign most users as Project Members or Editors. Use asset-level permissions for sensitive agents. Focus on getting value quickly, not perfect structure.
Common mistakes to avoid:
  • Creating too many projects too early
  • Over-engineering permissions
  • Spending too much time on structure instead of building

​
Asset organization within projects

Once you’ve structured your projects, organize assets within them using folders and naming conventions.
Use folders to organize assets in ways that make sense for your workflow:By asset type:
Project: Marketing
├── 📁 Agents
│   ├── Content Writer Agent
│   ├── SEO Optimizer Agent
│   └── Social Media Agent
├── 📁 Tools
│   ├── Content Analysis Tool
│   └── Keyword Research Tool
├── 📁 Knowledge
│   ├── Brand Guidelines
│   └── Product Information
└── 📁 Workforces
    └── Content Production Workforce
By use case or workflow:
Project: Sales
├── 📁 Lead Generation
│   ├── Lead Finder Agent
│   ├── Lead Enrichment Tool
│   └── Company Database (Knowledge)
├── 📁 Lead Qualification
│   ├── Lead Scorer Agent
│   └── Qualification Criteria (Knowledge)
└── 📁 Outreach
    ├── Email Writer Agent
    └── Outreach Workforce
By status or stage:
Project: Customer Success
├── 📁 Active / Production
├── 📁 In Development
├── 📁 Testing
└── 📁 Archived
Establish clear naming conventions for consistency across your organization:For projects:
  • Use descriptive names: Marketing - Production not Mktg Prod
  • Include environment if applicable: Sales - Development
  • Use consistent separators: - or |
For assets:
  • Start with asset type: Agent: Lead Qualifier or Tool: Data Enrichment
  • Include purpose: Agent: Customer Support - Tier 1
  • Use version numbers if needed: Agent: Content Writer v2
  • Avoid special characters that may cause issues
For folders:
  • Use emojis for visual clarity: 📁 Active Agents, 🔧 Tools, 📚 Knowledge
  • Keep names short and clear
  • Use consistent capitalization

​
Permission management

Owner role:Assign to 1-2 people maximum (CEO, CTO, or Head of Operations). These users have full control including billing.Admin role:Assign to IT leads, platform team, or workspace admins. Typically 2-5 people depending on company size. These users manage projects, users, and security.Member role:Default role for most users. Can create their own projects and assets. Good for power users and builders.Viewer role:For external collaborators or users in onboarding. Cannot create anything until assigned to a project. Good for stakeholders who need visibility only.
Admin role:Assign to project owners (1-2 per project). These users manage project permissions and settings.Editor role:Assign to core contributors and builders. Can create and edit all assets in the project. Typically 20-40% of project users.Member role:Default role for most project users. Can create their own assets but don’t see others’ by default. Good for independent contributors.Chat role:For users who only need to interact with agents via Chat. Cannot access the web app. Perfect for end users and external users.Viewer role:For stakeholders who need visibility only. Cannot run or edit anything. Add only to specific assets they need to see.
Default approach: Let project-level permissions handle most access control.When to use asset-level permissions:
  • Sensitive agents with confidential data
  • Agents that should only be run by specific users
  • Shared agents that need different permissions than project default
  • Agents used by external collaborators
Best practice: Start with project-level permissions and add asset-level permissions only when needed. Over-complicating permissions makes administration harder and can cause confusion.

​
Common organizational patterns

Choose the pattern that best fits your organization’s governance model:
A centralized team manages the platform and creates shared resources.Structure:
Organization: Acme Corp
├── Project: CoE - Shared Agents (managed by platform team)
├── Project: CoE - Shared Tools (managed by platform team)
├── Project: CoE - Knowledge Libraries (managed by platform team)
├── Project: Marketing (uses shared resources)
├── Project: Sales (uses shared resources)
└── Project: Support (uses shared resources)
Best for:
  • Companies with dedicated AI/automation team
  • Organizations wanting centralized governance
  • Companies with compliance requirements
Why this works:The CoE model ensures consistency and quality across the organization. A centralized team becomes experts in the platform, creates reusable resources, and maintains governance standards. Teams benefit from professionally-built shared resources without needing deep platform expertise.
Each team manages their own projects with light central governance.Structure:
Organization: Acme Corp
├── Project: Marketing (self-managed)
├── Project: Sales (self-managed)
├── Project: Support (self-managed)
├── Project: Product (self-managed)
└── Project: Shared Resources (light governance)
Best for:
  • Companies with autonomous teams
  • Organizations with distributed decision-making
  • Companies prioritizing speed over standardization
Why this works:The federated model empowers teams to move quickly and innovate independently. Each team controls their own destiny while a lightweight shared resources project prevents complete duplication. This works well for organizations that value team autonomy over centralized control.

​
Migration and restructuring

​
When to restructure

Consider restructuring when:
  • Projects have become too large or complex
  • Permission management is becoming difficult
  • Usage tracking doesn’t align with business needs
  • Teams are duplicating work across projects
  • Compliance or security requirements change

​
How to restructure safely

1

Plan the new structure

Document your current structure and design the new structure. Get buy-in from stakeholders.
2

Create new projects

Set up new projects with proper permissions before moving assets.
3

Move assets gradually

Move assets in phases, starting with non-critical ones. Test after each phase.
4

Update permissions

Ensure all users have appropriate access in the new structure.
5

Communicate changes

Notify all users about the new structure and any changes to their access.
6

Archive old projects

Once migration is complete, archive (don’t delete) old projects for reference.
Restructuring can temporarily disrupt access. Plan migrations during low-usage periods and communicate clearly with all users.

​
Governance and maintenance

Document policies for:
  • Who can create new projects
  • Naming conventions for projects and assets
  • Approval process for new integrations
  • Usage limits and escalation procedures
  • Asset archival and deletion policies
Share these policies in a central location that’s easy to find and keep them updated as your deployment evolves.
Conduct quarterly audits to:
  • Review project structure and usage
  • Remove inactive users and projects
  • Verify permissions are still appropriate
  • Identify duplicate or unused assets
  • Check compliance with policies
Regular audits prevent organizational drift and keep your structure aligned with your business needs.
Every project should have:
  • Primary owner (Project Admin) — responsible for day-to-day management
  • Secondary owner (Project Admin) — backup for primary owner
  • Executive sponsor — business stakeholder who approves major changes
Clear ownership ensures accountability and makes it easy for users to know who to contact for access or questions.
Track these metrics:
  • Number of active projects and assets
  • Users per project
  • Usage per project (credits consumed)
  • Permission changes and access requests
  • Asset creation and deletion rates
Use these metrics to identify:
  • Projects that should be merged or split
  • Users who need training or support
  • Opportunities to create shared resources
  • Potential security or compliance issues
Data-driven optimization keeps your structure efficient as your organization grows.

​
Industry examples

See how organizations in different industries structure their Relevance AI deployments:
  • Technology / SaaS
  • Professional Services
  • Financial Services
  • E-commerce / Retail
Organization: TechCorp
├── Project: Product - Production
├── Project: Product - Development
├── Project: Engineering - Production
├── Project: Engineering - Development
├── Project: Customer Success
├── Project: Sales & Marketing
├── Project: Shared - Documentation & Knowledge
└── Project: Sandbox
Key characteristics:
  • Separate production and development environments
  • Engineering and Product have their own projects
  • Shared documentation project for company knowledge

​
Frequently asked questions (FAQs)

Start with 3-5 projects and add more as needed. Most organizations have 5-15 projects. If you have more than 20 projects, consider consolidating.
Yes, but this requires proper permissions. Contact support for assistance with bulk asset moves.
For Enterprise deployments, yes. This provides safer testing and better governance. For smaller teams, you can use folders within a single project.
Create a “Shared Resources” or “Platform” project that all teams can access. Use asset-level permissions to control who can edit vs. use shared resources.
Use folders extensively to organize by use case, status, or team. Consider splitting into multiple projects if agents serve very different purposes.
Yes, users can be members of multiple projects with different roles in each project.
Require approval for new projects, conduct regular audits, and establish clear criteria for when a new project is needed vs. using an existing one.
Start with project-level permissions for simplicity. Add asset-level permissions only for sensitive or special-case assets.