Creating Users

Creating a user establishes an identity for a person or connected system and gives that account the access needed for its work. Decide who owns the account, where it belongs, and which process will maintain it before issuing credentials. This keeps a new account's access and eventual removal aligned with the colleague, Partner, or integration it serves.

Account Placement and Folder Preparation

Create separate human and machine accounts. Place each account in the Site and Workspace that owns its work. For deployments spanning Child Sites, User Management Across Parent and Child Sites explains account and credential scope. For shared file access, Team Collaboration starts with individual users, Groups, and folder permissions in the Default Workspace.

Regular users who share access requirements should receive permissions through Groups. Create external organizations as Partners and add their people and machine accounts as Partner Users, except where the documented cross-Partner access requirement calls for a regular user. Partner Users share their Partner's permissions; they cannot join Groups or receive individual folder permissions.

Arrange the folders around the work the accounts need to perform. If each user needs an individual folder, a simple arrangement such as users/alex and users/blair may suffice. Departments or regions can add useful structure, such as users/accounting/alex or users/EU/blair. When an existing directory or system defines that organization, align the folders with it. Users working together may instead need shared team folders.

Folders can be prepared manually or through automatic user-folder creation. Verify the automatic feature's naming, membership criteria, and permission behavior; do not assume that users/username is created by default. If all folder permissions must be assigned through Groups, plan the Group assignment too. A file system layout or FTP/SFTP starting folder changes the user's view, while folder permissions govern the operations they can perform.

Branding, menu customization, and upload restrictions can prepare the experience users encounter. Apply the ones your deployment needs; they are not prerequisites for creating an account.

Provisioning Methods and Ownership

For a small number of accounts, create users on the Users page in the web interface. Cloning an existing user can supply a starting configuration. For a larger migration or batch, Bulk User Import creates accounts from a CSV file. Account requests provide an approval path when people need to ask for access before an administrator creates their account.

Use SCIM provisioning when an identity provider manages the relevant users and Groups. Test creation, membership changes, updates, and deactivation through that provider. Just-in-time provisioning creates an account at first SSO sign-in; it does not by itself establish an offboarding process. LDAP/Active Directory has its own authentication and synchronization configuration.

Automated Provisioning also covers provisioning through APIs, SDKs, CLI tools, and supported iPaaS operations. Give one process authority over each account's lifecycle. Independently maintaining the same users through SCIM, Terraform, and manual changes can produce conflicting updates. SCIM's manual management controls determine whether administrators can also create or change accounts directly in Files.com.

Record who approves access and who maintains the account. For temporary access, plan an expiration date. For machine credentials, plan rotation using the applicable Key Lifecycle Rules. Account creation is also the time to establish which process will remove access when the work ends.

Individual User Creation

On the Users page, create an individual account with a username that meets the site's username rules. Select its authentication method, Group membership, and folder permissions. Advanced settings include administrative authority, IP restrictions, the Shared/Bot user setting, allowed protocols, SFTP/SSH keys, and an expiration date.

For people setting their own password, Email Signup sends the user a link to create it. Administrators with permission to change passwords can instead choose Password and set it directly. For an unattended account using None (Use SSH or API Keys), create the required keys before the system can connect. Apply the authentication method's requirements and the site's applicable two-factor policy.

Delegated User Creation

Site Administrators can create users across the site. Workspace Administrators can create users within their Workspace. Group Admins can create users within their assigned Group when Site Administrators enable that capability site-wide. Partner Admins can create users for their own Partner. Users can also be created directly within a Child Site, where they inherit that site's settings, authentication configuration, and access boundaries.

Cloning Users

Cloning pre-populates most of the new user's settings from an existing user, including Group membership and permissions. Review the copied configuration against the new account's purpose before creating it. Cloning also copies Additional Email Recipients, so check who should receive the new account's notices.

User Account Requests

Account requests let external parties ask for access when your process requires approval before account creation. This is useful for occasional exchanges where pre-provisioning accounts would create accounts that may never be used.

Site Administrators enable Allow non-users to request a user account under User Settings. The login page then displays a Request an account link beneath Log in, where the visitor submits their information.

Creating a user from the User Requests table pre-populates the creation form with the requester's name and email address. The administrator supplies the username, permissions, and other required configuration before creating the account.

The Notify admins of requests for a user account setting under User Settings emails Site Administrators when a request arrives. Every Site Administrator who has not opted out of site alert emails receives that notification.

Verifying the Account

Verify authentication, allowed operations, and denied access through the interface the person or system will use. A successful login alone does not establish that the account can complete its work. For an SFTP integration, test the intended transfer and path; for a Partner, also check that another Partner's area remains inaccessible.

Check Access shows effective folder permissions. A Site Administrator can use User Impersonation to inspect the user's web interface and configuration, but impersonation prohibits file operations, including opening and downloading files. It does not replace a transfer test using the actual account.