Files.com user accounts represent either a person or automation. This distinction drives how you set authentication, apply security controls, and interpret audit logs. Account design breaks down when a human login and a machine credential share the same identity.

When teams plan their Files.com environment, the same questions come up: whether automation uses the same account as a person, whether a person signs in with the same account that automation uses, and how to structure accounts for integrations versus people. The answers are consistent across enterprises. Use human accounts for people, use machine accounts for automation, and do not use a single user account for both.

Human User Accounts

A human user account maps one-to-one with an individual person who accesses Files.com interactively. Each account has a single owner, signs in through the web interface (Web UI) and client apps, and typically authenticates with a password or SSO. The one-to-one mapping is what makes auditing meaningful, since every action ties back to a specific person.

Use groups and folder permissions to give teams shared access. Do not share a single username and password across people.

Machine Accounts (Service Accounts)

A machine account maps to a workload, not a person. A script, integration, agent, or device uses the account programmatically, authenticates with API keys or SSH keys, and typically connects over API, SFTP, or FTP. Permissions stay stable so the workload can run unattended. The Shared/Bot user setting relaxes requirements that apply to human users, so it is well suited to machine accounts.

When you create a machine account, select an appropriate authentication method. For unattended machine credentials, use None (Use SSH or API Keys), then authenticate with API Keys or SFTP/SSH keys.

Do Not Mix Human and Machine Usage in One Account

Do not use the same username for interactive sign-in and automation.

This is the pattern to avoid:

A person signs in to the web interface with a username and password.
A script or integration uses the same credentials over API, SFTP, or FTP.

This causes predictable failures:

Authentication policies conflict. Human sign-in requires controls that break automation.
Auditing loses meaning. Logs show one identity for multiple actors.
Incident response slows down. You cannot tell whether a person or a system acted.

Account Patterns to Use

One Account Per Person

Create a separate user for every person who accesses Files.com. This keeps access changes clean, makes audits meaningful, and prevents one person from breaking another person's access. When multiple people need the same access, use groups and permissions.

One Account Per System

Create a separate machine account for each integration or workload, and do not share those accounts with human users. When multiple systems need access, give each one its own machine account and scope the permissions to the exact folders and protocols that workload requires. This makes the audit trail clear about which account performed each action.

Shared/Bot User Setting

Shared/bot user is a per-user setting that locks down self-service changes and removes 2FA requirements. It exists to support machine accounts and other non-person identities.

Using Shared/bot user for a shared human account reduces security and audit quality. Avoid it for team logins. Use individual human users plus groups instead.

Effects of Shared/Bot User Setting

When Shared/bot user is enabled, the user cannot change its own password, email address, or time zone. Locking down these self-service changes keeps the account stable so the scripts and automations that depend on it run without disruption.

Password expiration does not apply to Shared/bot users, and the Require password change on next login option has no effect on them, since both settings can disrupt workflows for scripts and automated bots. Site Admins can still change passwords for Shared/bot users manually.

Site Administrators who need to exempt a specific user from password expiration without applying the full Shared/bot user restrictions can use the Never Expires per-user option instead.

Files.com also exempts Shared/bot users from Two-Factor Authentication (2FA) requirements. 2FA requires a physical device, which can only be held by a single person, not by a bot or automated script.

Files.com blocks Shared/bot users from holding Site Administrator permissions, because Site Administrators have access to very powerful permissions that typically need to be secured with settings like 2FA. To promote a Shared/bot user to an admin, first disable the Shared/bot user setting, then enable the Administrator access setting. For administrative roles and scope, see Administrative Permission Levels.

Audit and Ownership Expectations

Files.com records every action under the account that signed in. When people share one login, the audit trail cannot show who did what. Give each person their own account and use separate accounts for automated workloads, so the history logs attribute each action to a single owner.

Human Users and Machine Accounts