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, including their credentials, group memberships, and account lifecycle. Child Site Administrator access does not grant authority to manage Parent Site accounts or configuration. Administration of ordinary folder permissions and email notifications follows the folder being administered, subject to the Parent Site's directory-sharing choice.

Parent Site Administrators, Workspace Administrators, and Group Admins manage the accounts within their respective scopes and enabled capabilities, even when a user has Child Site Administrator access. That Child Site grant does not place the account above its parent-site administrators. Parent and Child Site Administrators explains the effects on credentials and account access.

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.

Parent Site Directory Sharing

Sharing the Parent Site directory lets Child Site administrators find centrally managed users and groups when assigning folder access or configuring email notifications. A central team can maintain the accounts while local administrators decide who needs access to the folders they administer.

A Parent Site Administrator configures Share Users and Groups With Child Sites under Settings > Child Sites > Settings on the Parent Site. The setting is on by default and applies to all of that Parent Site's Child Sites. The Parent Site controls this choice; changing a Child Site's own settings does not enable access to its parent's directory.

With sharing on, Child Site Administrators, including Parent Site users with delegated Child Site Administrator access, and Folder Admins working in the Child Site's Default Workspace can browse the Parent Site's Default Workspace users and groups. This includes identities with no existing access to the Child Site.

They appear in the folder-permission and email-notification selectors alongside the Child Site's own users and groups. Shared entries expose the directory information available to a Folder Admin on the Parent Site, without granting Parent Site account-management authority.

Directory visibility and permission to make changes are separate. An administrator can assign or revoke ordinary folder permissions and configure notifications only on folders they administer. Only a Parent Site Administrator can grant or remove delegated administrative access to a Child Site.

With sharing off, administrators whose authority is limited to the Child Site cannot browse the Parent Site directory or create folder permissions or notifications naming another Parent Site user or a Parent Site group. This restriction also applies through the API, even when the identity is already known.

Parent Site Administrators and Parent Site Folder Admins retain the directory access their Parent Site permissions already provide. The API reference covers programmatic configuration.

Turning sharing off does not revoke existing folder permissions or delete existing email notifications. Child Site Administrators and Folder Admins can still remove existing folder grants and manage or delete existing notifications on folders they administer. Stopping new assignments is separate from removing access or subscriptions already in place.

Sharing includes only Parent Site identities in the Default Workspace. Parent Site users and groups in Custom Workspaces are excluded. Workspace Administrators and Custom Workspace users gain no Parent Site directory access through this setting; their user and group administration remains within their Workspace scope.

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.

Account and Credential Policies

A centrally managed employee keeps the Parent Site's account policies wherever they work. Switching into a Child Site changes the resources they can reach, without creating another identity or transferring account management to the Child Site.

The Parent Site's 2FA requirements, password rules, login lockout, country restrictions, IP restrictions, and SSO configuration govern its users on every Child Site they can access. Its User Lifecycle Rules and each user's Access expiration date also govern those accounts. A Child Site's corresponding settings govern users created directly in that Child Site.

User-owned SSH keys and API keys for integrations belong to the account's Site and follow that Site's key settings and Key Lifecycle Rules. Delegated access does not turn Parent Site credentials into native Child Site credentials.

Desktop and Mobile App connections are the exception. When a Parent Site user connects an app to a Child Site, the app's dedicated credential belongs to that Child Site. The Child Site controls whether the app is enabled, its session lifetime, and session IP pinning. The person's browser sign-in still follows the Parent Site's authentication requirements.

A Child Site can also add its IP whitelist as a second connection requirement through Apply IP Whitelist to Parent Site Users. This supplements the Parent Site's IP rules; it does not replace them. It does not apply to Parent Site Administrators accessing Child Site files through the Parent Site's underscore folder. Accessing Child Sites explains the scope of this additional check.

Resource Policy and Offboarding

Central account management and local resource management work together. A Child Site's folder settings and Share Link policies govern resources located on that Child Site, whoever owns them. The account's Site governs what happens to its individually owned resources when that account expires, is disabled, or is deleted.

For example, a Parent Site user can own a Share Link on a regional Child Site. The Child Site's ordinary Share Link expiration limit applies to that link. The Parent Site's Auto-revoke Share Links for deactivated users setting determines whether disabling or deleting the owner revokes it, and whether the owner's Access expiration date limits it. The Child Site's auto-revocation setting applies to its own users, rather than Parent Site users. Ownership and Sharing Policy explains the expiration rules and exemptions.

Removing delegated Child Site access ends the person's access through that grant; it does not revoke their existing Share Links or transfer their resources. Retained resources still participate in the owning account's later lifecycle changes, even if the account can no longer reach that Child Site. A Child Site Administrator who needs a link to stop working can revoke it directly.

Offboarding therefore includes reviewing resources across all Child Sites where the account owns them. Deleting Users explains the effects for each resource type, including Automations, Remote Servers, Custom Forms, and folder settings. When deleting with reassignment, the replacement owner must be another user in the same Site and Workspace and have access to every Child Site containing resources being transferred. Reassignment preserves the resources' existing Workspace requirements.

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. Creating Users connects that choice to account configuration and verification. Plan access removal in the system that owns each account.