Spaces

Spaces are isolated, access-controlled silos where your team organizes work for a client, business, or operational area. Each Space keeps its context and resources separate from every other Space unless you explicitly connect them. Use a Space when its contents should share one access boundary and one working context.

​

What lives in a Space

A Space contains the resources that people and agents use to complete work:

• Pages that preserve context, analysis, and working knowledge
• Files used as source material
• Connections to external systems
• Automations and their run history
• Chats grounded in the Space’s available context

Connections are not available to a Space by default. You must explicitly expose each connection before its contents can be used there.

​

Membership and roles

Membership determines what each person can see and change within a Space. The following table compares the actions available to each Space role.

​

Organization Owners and Admins

Organization Owners and Admins are automatically members of every Space and have edit access. They can oversee work across the organization without being invited to each Space individually.

​

Connections

A Space cannot access an organization’s connections until they are explicitly exposed to it. This prevents unrelated Spaces from seeing connected records by default. A connection owner can expose their connection directly. A Space Owner or Contributor can also request access from the connection owner. The connection remains unavailable until the owner approves the request and exposes it to the Space. Once a connection is exposed, its configured data scope becomes available to the Space’s agents, chats, pages, and automations. Supported connection triggers also become available when you configure an automation.

​

Linking Spaces Together

Linked Spaces provide one-way visibility from a parent Space into one or more child Spaces. Use links when work must remain separated at the child level but another Space needs consolidated visibility. When a parent Space links to a child Space:

• Members of the parent can read the child’s contents.
• The child cannot see the parent’s contents.
• One child cannot see another child through their shared parent.
• Linked visibility continues through additional child links.

Linked access is read-only. To modify a page, file, automation, connection, or other resource in a child Space, a person must also be a direct member of that child Space with the required role. Creating a link requires link-management access in both Spaces. Removing a link requires link-management access in the parent Space.

​

Example: A Client with Multiple Businesses

Suppose your firm manages a client’s personal finances and six separate businesses. Create an individual Space for the client and each business so their records, files, and automations do not become commingled. Your management team can then use a parent Space linked to all seven child Spaces. The parent provides consolidated visibility into customer sentiment, team efficiency, and emerging issues while each child’s working context remains isolated.

​

Example: An Admin Space Overlooking Multiple Projects

Suppose your organization runs several projects, each with its own team, files, pages, connections, and automations. Create a separate Space for each project so its working context remains isolated from unrelated work. Create an Admin Space and link each project Space as a child. The Admin Space gives leadership a consolidated view of project status, blockers, team activity, and emerging risks. Project teams cannot see the Admin Space or one another’s Spaces through these links, and members of the Admin Space need direct membership in a project Space to modify its contents.