Parent and Child Sites

A person can work on several Child Sites through one Parent Site account. Each Child Site has its own configuration and resources, but entering it does not create a local account or transfer responsibility for the person's identity. The Parent Site continues to govern that account; the Child Site governs the resources located there.

This distinction matters when evaluating a Child Site's access requirements or offboarding someone who has worked across Sites. A local authentication policy does not redefine a centrally managed account, and removing that person's access does not necessarily retire the links or workflows they established.

Account and Connection Policy

The Site where a user is managed supplies their account policy wherever they have access. For a Parent Site user, the following scopes apply:

Child Site account policies govern users created directly in that Child Site. A native Child Site account and a Parent Site account remain separate identities, even if they represent the same person. Direct FTP, SFTP, or integration API access to a Child Site requires its native credentials.

Child Site Administrator access does not grant authority to manage Parent Site accounts, credentials, or Group memberships. Directory sharing can expose Parent Site directory entries for folder-permission and notification assignments without granting account-management authority.

Connection Exceptions

Desktop and Mobile App credentials belong to the Site the app connects to. A Parent Site user's browser authentication follows the Parent Site's requirements, while the Child Site controls the resulting app connection. Desktop & Mobile App Sessions explains the distinction between identity checks and the app's continuing credential.

Apply IP Whitelist to Parent Site Users is off by default. Enabling it adds the Child Site's whitelist when a Parent Site user enters or continues using the Child Site, including through the apps. It does not apply to Parent Site Administrators working with Child Site files through the Parent Site's underscore folder. IP Restrictions for Parent Site Users describes that boundary.

Resource Policy and Account Lifecycle

A Child Site's folder settings and ordinary Share Link policies apply to resources located there, whoever owns them. Owner-based lifecycle follows the Site that manages the account. These controls address different responsibilities: the Child Site sets the rules for its files and sharing, while the Parent Site decides what happens to its user's resources when the account's access ends.

For individually owned Share Links, the owner's Site supplies Auto-revoke Share Links for deactivated users and the associated Access expiration date limit. With the setting enabled on the Parent Site, disabling or deleting a Parent Site user revokes their links on the Parent Site and all Child Sites. The Child Site's own setting governs its native users, rather than Parent Site users.

The owner-expiration rules and exemptions also apply across Sites. A Child Site's ordinary Share Link expiration limit remains independent, and group-owned links remain separate from a departing member's individually owned links.

Removing delegated access does not revoke an existing Share Link or detach retained resources from the owning account's later lifecycle changes. A Child Site Administrator can revoke a link directly. Deleting Users explains the separate effects for Automations, Remote Servers, Custom Forms, and other resources.

Deletion with reassignment requires another user in the departing account's Site and Workspace, with access to every Child Site containing resources being transferred. This includes retained resources on Child Sites the departing user can no longer access. Reassignment preserves the resources' existing Workspace requirements; it does not relocate them.