User Onboarding & Offboarding

Onboarding establishes an account's purpose, authentication, access, and owner. Offboarding removes that access and addresses the resources and workflows that may continue after the account stops being used. Plan both when creating the account.

Identify the Participant and Its Scope

Create individual accounts for people and separate machine accounts for applications or unattended transfers. Place each account in the Site and Workspace that should own it. For cross-site deployments, review User Management Across Parent and Child Sites before issuing protocol credentials or API keys.

Use groups for regular users who share access requirements. 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.

Record who approves access and who maintains the account. A Partner Admin can maintain the users within the capabilities allowed for that Partner. Group Admins and Workspace Administrators provide other forms of delegation; each has a different administrative scope.

Choose the Provisioning Method

Use SCIM provisioning when an identity provider manages the relevant users and groups. Configure and test creation, group membership changes, updates, and deactivation through that provider. Just-in-time provisioning creates an account when the user first signs in through SSO; it does not by itself establish an offboarding process.

For a small number of accounts, create users in the web interface. User Requests provides an approval path, and bulk import handles larger batches. APIs, SDKs, the CLI, and supported iPaaS operations can provision accounts from your own systems.

LDAP/Active Directory has its own authentication and synchronization configuration. Follow the selected integration's reference instead of assuming every SSO method provisions and removes accounts the same way.

Give one process authority over each account's lifecycle. Independently managing the same users through SCIM, Terraform, and manual changes can produce conflicting updates.

Configure Authentication and Access

Choose authentication methods suitable for the participant. People may use SSO or password authentication with the applicable two-factor policy. Applications commonly use API keys or SFTP/SSH keys. Enable only the protocol privileges needed for the job, without assuming that an external person never needs browser or Desktop App access.

Assign regular users' folder access through groups where practical. Effective access can come from several groups or direct assignments, so removing one grant does not necessarily remove access. Partner permissions are managed separately at the Partner level.

Folder layout and permissions are also distinct from a client's starting directory. FTP/SFTP folder settings control the home and client-root behavior for those interfaces. They do not replace the folder permissions that govern file actions.

If each user needs a new folder, configure automatic user-folder creation and verify its naming, membership criteria, and permission behavior. Do not assume a folder such as users/username is created by default. Where all folder permissions must be managed through groups, plan the group assignment as well.

Set an access expiration date for temporary accounts where appropriate. For machine credentials, plan rotation and review the applicable Key Lifecycle Rules.

Verify the User's Experience

Use Check Access to inspect effective folder permissions. A Site Administrator can also use Impersonate User to inspect the user's web interface, but impersonation prohibits file operations, including opening and downloading files. It is not a substitute for testing the intended transfer as the real account.

Verify authentication, allowed operations, and denied access through the interface the person or system will actually use. For a Partner, include a check that another Partner's area remains inaccessible.

Remove Access and Review Dependencies

For a provider-managed account, perform the lifecycle change in the authoritative identity system and verify its result in Files.com. For manually managed accounts, disable access when it should stop and delete the account when appropriate. User Lifecycle Rules can automate inactivity-based actions; coordinate them with the identity provider's lifecycle policy.

Review user API keys, SSH keys, group membership, delegated site access, notifications, Share Links, and owned resources. Site-wide API keys are independent of the administrator who created them, so deleting that administrator is not a credential-revocation plan.

Disabling a user leaves Share Links available by default unless the site's auto-revocation policy applies. Deletion also needs an explicit resource review. Reassign or retire Automations according to their version's ownership rules; a v1 Automation can depend on a Folder Admin user's permissions.

Deleting an account does not delete its stored files or reduce storage usage. Retain or remove those files under the appropriate policy. If an account is restored, review its recovered credentials and permissions before returning it to service; Restoring Users describes what is recovered and what must be reassigned.