User Management Across Parent and Child Sites

Where an account is created determines who can manage it and how it can connect to a Child Site. Choose that location before provisioning users or issuing credentials. A parent-site account with delegated access and an account created directly in a Child Site are different identities, even when they represent the same person.

Centralized User Management

Create accounts on the Parent Site when a central team owns their lifecycle and they need to work across sites through the supported interfaces. A Parent Site Administrator can grant those users or groups folder permissions or administrative access on Child Sites. Parent Site Administrators themselves have access to all Child Sites.

The Parent Site remains responsible for these identities. Child Site Administrators can see their activity and delegated permissions but cannot manage the parent-site accounts or change those permission assignments. Changes to those users belong in the Parent Site.

This model can use the Parent Site's SSO and SCIM configuration for centrally managed employees. Provisioning an employee there does not create a native account in every Child Site.

Independent Child Site Users

Create accounts directly in a Child Site when its administrators own the users' lifecycle, when users belong only to that site's organization, or when they need direct protocol or API access to it.

Native Child Site users sign in at the Child Site's domain. They cannot receive access to the Parent Site or sibling Child Sites. The Child Site has its own SSO configuration and can have its own provisioning integration.

A Parent Site Administrator still retains oversight of the Child Site. Independent account management does not remove that parent administrative authority.

Match the Account to the Interface

Accessing Child Sites describes each interface's behavior. Parent-site users with delegated access can work through the web interface and supported Desktop and Mobile App access. They cannot use their parent-site credentials to authenticate directly to the Child Site over FTP or SFTP.

An API key belongs to one site. A key issued on the Parent Site does not become a Child Site key because its user has delegated access. Create a native Child Site account and key for an application that must call that Child Site directly. Parent-site cross-site file operations are a separate capability, accessed through the Parent Site.

Operators using the CLI across several sites can maintain a profile for each site's credentials. Record which site owns each account and key so a rotation or access change is applied in the right place.

Combine the Models Deliberately

A mixed model can keep human administrators on the Parent Site while creating machine accounts in each Child Site for direct SFTP or API connections. Other organizations keep all identities local to each Child Site because each business unit administers its own access.

Document which users belong where and who handles their removal. Revoking one native account does not revoke a separate account for the same person on another site. A change in identity placement can require new accounts and credentials, updates to integrations, and a review of retained access and history.

The permissions audit export from the Parent Site includes permissions across its Child Sites. Use it alongside the relevant user inventories when reviewing cross-site access.

Compare with Workspaces

If separate site settings are unnecessary, Workspaces can group related resources within one site. Users created in Custom Workspaces are scoped there; Default Workspace users and groups can receive supported cross-workspace access. Workspaces do not eliminate identity-placement decisions, but use a different boundary from Child Sites.

Account Structure & Environments helps choose the arrangement before provisioning. User Onboarding & Offboarding covers the lifecycle within that arrangement.