Human Users and Machine Accounts

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.

Common Design Questions

These questions come up when teams plan their Files.com environment. They ask whether automation uses the same user account as a person. They ask whether a person signs in with the same account that automation uses. They ask how to structure accounts for integrations vs people.

The answers are consistent across enterprises. Use human accounts for people. Use machine accounts for automation. Do not use a single user account for both.

Human User Accounts

Human user accounts map one-to-one with an individual person who accesses Files.com interactively.

Human accounts have a single owner. They sign in interactively through the web interface (Web UI) and client apps. They commonly authenticate with passwords or SSO. They exist to make auditing meaningful by attributing actions to a 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)

Machine accounts map to a workload, not a person. A script, integration, agent, or device uses the account programmatically. Machine accounts authenticate with API keys or SSH keys. They commonly connect over API, SFTP, or FTP. They keep permissions stable so a workload can run unattended. A Shared/Bot user setting exists to make using machine accounts easier by relaxing requirements that must apply to human users.

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

Use these patterns when defining your user accounts for human accounts and machine accounts.

One Account Per Person

Create a separate user for every person who accesses Files.com. This keeps access changes clean and makes audits meaningful. It also 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 per integration or workload. The system or machine accounts must not be shared or used by human users. It is also best practice to separate machine users if you have multiple systems that need access, scope the permissions to the exact folders and protocols required for each account. This provides audit clarity and knowing which account performed an 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, as locking down changes makes it for better operational stability and control to ensure the machines and automations that rely on the account run without disruption.

Password expiration does not apply to shared/bot users. The Require password change on next login option does not apply to Shared/bot users as these settings can disrupt workflows for scripts or automated bots. Site Admins can still manually change passwords for Shared/Bot users.

Files.com exempts shared/bot users from Two-Factor Authentication (2FA) requirements. 2FA is disabled for Shared/Bot users as 2FA requires a physical device, which would only be able to be possessed by one physical person and not 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 and typically want to secure access using settings like 2FA.

Because of all the restrictions listed here, Shared/Bot users may not also be site admins. To promote a Shared/Bot user to an admin, you must first disable the Shared/Bot user setting before you can enable the Administrator access setting.For administrative roles and scope, see Administrative Permission Levels.

Audit and Ownership Expectations

Files.com records actions under the account that signed in. When people share one login, the audit trail can’t show who did what in Use separate human accounts for people and separate machine accounts for automation so activity stays clear.

When everyone uses the same login, it's hard to track who did what. For better clarity, give each person their own account and use separate accounts for automated tasks which can be viewed in history logs.