Skip to main content
This guide explains how Organizations, Roles, Agent Access, Sharing, and Environments work in Inya. It is designed for teams that want structured collaboration, controlled access, and a safe promotion workflow before going live.

​
Who Should Use Organizations?

Organizations are ideal for:
  • Teams building agents collaboratively
  • Companies separating development and testing responsibilities
  • Businesses that need controlled access to agents
  • Teams that want structured Development → Staging → Production workflows
If you are working alone, you may use your Personal workspace. If you are working with a team, using an Organization is strongly recommended.

​
Why Use an Organization?

Using an Organization provides:
  • Clear role-based access (Developer, QA, Org Admin)
  • Controlled agent visibility
  • Structured testing before production readiness
  • Centralized ownership and oversight
  • Safe collaboration without accidental overwrites
Organizations ensure that only the right people can build, test, and prepare agents for deployment.

​
1. Understanding Organizations

​
What is an Organization?

An Organization is a shared workspace where:
  • Team members collaborate
  • Agents are created and managed
  • Agents move through Development → Staging → Production
Deployment to live infrastructure is handled by the Inya team. Agents must be in the Production environment before deployment can be requested.

​
How to Create an Organization

Organizations are not created through the UI. If you need an Organization set up, please contact us and we will create it for you. We will also assign the initial Org Admin from our end. If you need additional Org Admins added later, you can contact us for assistance.

​
2. Roles

An Organization includes three user roles:
  • Org Admin
  • Developer
  • QA
Permissions are currently fixed. Custom roles and granular permission editing are coming soon.
RolePrimary Responsibility
Org AdminManage team members and oversee all agents
DeveloperBuild and manage agents in Development
QATest agents in Staging and mark them ready

​
3. Role Responsibilities

​
Org Admin

The Org Admin oversees the organization. Can:
  • Add/Remove Developers and QA users
  • Change user roles (Developer ↔ QA)
  • View and edit all agents
  • Promote agents through environments

​
Developer

Developers are responsible for building agents. Can:
  • Create agents in Development
  • Edit agents in Development
  • Share agents with other Developers
  • Promote agents to Staging
Cannot:
  • Edit agents in Staging
  • Edit agents in Production
  • Deploy agents

​
QA

QA users validate agents before production readiness. Can:
  • View agents in Staging
  • Test agents
  • Mark agents as “Ready for Production”
Cannot:
  • Edit agents
  • Deploy agents
  • Access Development unless granted visibility through the environment workflow

​
4. Membership Concept (Agent Access)

Agent access works on a membership model. You can think of this as:
  • Agent Access List
  • Agent Membership
  • Agent Ownership & Sharing
When a Developer creates an agent:
  • That Developer automatically has membership
  • The Org Admin automatically has membership
No one else can see or access that agent unless it is explicitly shared. This ensures agents are private by default and only visible to intended collaborators.

​
Sharing Agents

Agents can be shared with other Developers within the Organization. When sharing an agent, there are two access levels:
  • Read-Only Access
  • Edit Access

​
Edit Access Rules

  • Only the bot owner (the Developer who created the agent) can grant edit access to another user.
  • A user who is not the bot owner can only share the agent as read-only.
This ensures ownership control while still enabling collaboration. Once shared:
  • Read-only users can view the agent configuration but cannot modify it.
  • Users with edit access can make changes in the Development environment.
QA users do not receive access through manual sharing.
QA visibility is granted automatically when the agent is promoted to Staging.

​
Deletion Rules for Shared Agents

If the agent creator (Developer A) shares an agent with another Developer (Developer B):
  • If Developer B deletes the agent from their view, only their membership is removed.
  • The agent itself is not deleted from the Organization.
  • The agent remains visible to the bot owner, Org Admin, and any other users who have access.
Only the bot owner can permanently delete the agent from the Organization.

​
5. Agent Visibility Rules

​
Default Visibility

When a Developer joins an Organization: They see no agents by default. They only see:
  • Agents they created
  • Agents shared with them

​
Org Admin Visibility

Org Admins have visibility into all agents within the organization.

​
QA Visibility

QA users:
  • Do not see Development agents
  • Automatically gain visibility when an agent is promoted to Staging
This ensures structured separation between building and testing.

​
6. Personal vs Organization Workspace

Every user has a Personal workspace. Organization workspaces are shared team environments. Currently:
  • Transfer of agents from Personal → Organization is not available
  • Agents cannot be moved between organizations
Agent transfer capabilities are coming soon. Agents must be created directly within the intended workspace.

​
7. Environments & Workflow

The workflow follows a strict linear structure: Development → Staging → Production There is currently:
  • No version history
  • No rollback
  • No skipping environments
  • Overwrite model (each promotion replaces the previous configuration)
Versioning and advanced release management capabilities are coming soon.

​
Development

Access:
  • Developer
  • Org Admin
Purpose:
  • Build and edit the agent
  • Modify prompts, flows, configurations
Action Available:
  • Promote to Staging
Effect:
  • Development configuration is copied to Staging
  • Any existing Staging version is overwritten

​
Staging

Access:
  • QA (full testing)
  • Org Admin (testing)
  • Developer (read-only)
Purpose:
  • Validate agent behavior
  • Conduct testing
Action Available (QA):
  • Mark “Ready for Production”
No editing is allowed in Staging.

​
Production

Access:
  • Org Admin (view and manage status)
  • Other users (view only)
Production represents the finalized configuration. Deployment is handled by the Inya team. An agent must be in Production before deployment can be requested.

​
8. Deployment Process

Deployment to live infrastructure is not triggered directly from the platform. Once:
  • The agent is in Production
  • Testing is complete
You can contact the Inya team to initiate deployment. Only agents in Production are eligible for deployment.

​
9. Integration Deletion Safety

If a Developer removes an integration from their agent:
  • It is removed from their access
  • It remains in the system if another agent is using it
An integration cannot be permanently deleted if it is linked to any active agent. This prevents accidental disruption of other team members’ agents.

​
10. Current Limitations

The following capabilities are not yet available but are coming soon:
  • Audit logs
  • Version history and rollback
  • Self-serve organization creation

​
Summary

Organizations provide:
  • Structured team collaboration
  • Clear role separation
  • Controlled agent visibility
  • Safe Development → Staging → Production workflow
  • Managed deployment process through the Inya team
This ensures predictable collaboration, clean testing flows, and controlled production readiness.