Connected Systems

Connecting Files.com to another system establishes a continuing relationship between two sets of permissions. Files.com permissions govern what the connecting account or workflow may request. The remote account, receiving service, and machine running a client have their own permissions and responsibilities. Administrators approving an integration need to consider both sides of that relationship.

A connection has a direction and a purpose. A client authenticating to Files.com uses the account or key issued for its work. Files.com connecting to remote storage uses the credentials configured for that destination. A directory connection can maintain accounts and memberships rather than transfer files. Choose the access for the operations the finished integration can perform, including its administrative effects.

Identity and Delegated Use

Connection eligibility and server identity answer different questions. Network and protocol controls determine whether a connection is permitted. Certificate and host-key checks establish which system receives credentials and data. Passing one check does not satisfy the others or expand the account's permissions.

Permission to use a connection can let people work with remote files without retrieving its underlying secret. The remote account's authority still applies. Likewise, a program running on an Agent host uses the operating-system account's access; a Files.com folder boundary does not impose the same boundary on that program.

Information Beyond the Connection

A successful transfer can leave files, credentials, or diagnostic copies on another system. The receiving system governs those copies. Review who can read local files and logs, which destinations receive event deliveries, and which team maintains remote authorizations when an integration changes or ends. Data Paths & Storage explains the distinction between the retained file and the systems that handle its contents along the way.