One of the most important decisions you make when setting up a parent and child site environment is where to create users. That choice determines who can manage users and their permissions, and whether those users can connect to the child site via FTP, SFTP, or API keys. If child site administrators need to manage access independently, create users in the child site. If access control is centrally owned, create users on the parent site.

If you change your approach after the initial setup, you'll need to recreate all the affected accounts, which impacts API keys, SSH keys, session history, and integrations tied to those users.

Where a User or Group Exists Determines Who Can Manage Them

A user's permissions can only be managed by an administrator from the site where that user's account exists.

A parent site administrator can grant and revoke permissions for parent-site users and groups on any child site. A child site administrator can only manage permissions for users and groups that were created directly in their child site. If a user or group belongs to the parent site, a child site administrator can see their permissions on the child site but cannot grant or modify them.

User Access to Child Sites

There are four different situations that give a user access to a child site.

They are a Parent Site Administrator, with full access to every child site automatically.
Their account on the parent site has been granted folder permissions scoped to paths inside the child site.
Their account on the parent site has been granted Site Administrator or Read-only Administrator access on the child site.
Their account was created directly in the child site.

The first three paths are forms of delegated access: the user is provisioned once on the parent site and their child site access is managed from there. As a result, users matching one of the first three paths are restricted in how they can connect to the child site; they cannot connect using any transfer protocol access or with an API Key.

Only the fourth path produces a user whose permissions a child site administrator can fully manage, and who can connect with FTP or SFTP to the child site.

Choosing a Model

Choose where you create users to reflect who is responsible for managing their access. The three models below describe the main patterns.

Centralized Model: Users and Groups Managed in the Parent Site

In a centralized model, all users are created in the parent site. Child sites hold files and folders, but identity and access control are owned by the parent site.

This model fits when a single team or administrator is responsible for access control across all sites, or when your organization provisions users through SSO and SCIM. With SCIM, users and groups flow into the parent site from your identity provider, and a parent site administrator grants child site access from there. Because the groups exist on the parent site, child site administrators cannot modify their membership or permissions on the child site. Child site administrators in this model are operators who manage files and folders, but they are not responsible for deciding who gets access.

The tradeoff is that child site administrators cannot control access for delegated users. To grant or change a parent site user's permissions on a child site, log in to the parent site and make the change there.

Decentralized Model: Users and Groups Managed in the Child Site

In a decentralized model, each child site manages its own users. Child site administrators create accounts, set permissions, and handle the full user lifecycle within their site.

This model fits when each child site operates as an independent unit with its own administrator who owns access control, when the child site serves a distinct subsidiary or acquired company whose users will never interact with the parent site, or when users need FTP, SFTP, or API key access. Protocol authentication cannot cross sites, so users who need protocol access to a child site must have a native account there.

If you want automated provisioning in this model, each child site needs its own SSO and SCIM configuration. The tradeoff is that there is no single place to see or revoke access across all sites. Each child site manages its own users independently.

Mixed Model: Users and Groups Managed in Both Parent and Child Sites

Some organizations use both approaches. A common pattern: service accounts and protocol users are created natively in each child site because they need FTP or SFTP access, while human users are created on the parent site and delegated to child sites through SSO and SCIM.

If you use a mixed model, document which user types belong where. The distinction between a parent site user and a child site user is not always visible in the interface, and child site administrators who don't know the model will hit unexpected permission errors.

Child Site Administrator Limitations

When a user's account comes from the parent site, a child site administrator can see that user performing actions in audit and history logs, but cannot view or list them in the user management interface and cannot grant, modify, or revoke their folder permissions on the child site.

When a user's account was created in the child site, the child site administrator has full control: creating accounts, setting permissions, and managing the complete user lifecycle.

Workspaces as an Alternative

If you need delegated administration but don't need the hard environment boundaries that child sites provide, Workspaces may be a simpler fit. Workspace Administrators manage their own users, groups, and folders within a single site without the cross-site permission constraints described in this guide. Workspaces can also be used alongside parent and child sites. Choosing between child sites, workspaces, and partners often comes down to how much isolation is required for your business units.

Designing User Management Across Parent and Child Sites