Share Link Access and Identity

Share Links give recipients a way to work with selected files without becoming Files.com users. Their access comes from the Share Link's configuration, rather than the recipient's folder permissions. This makes sharing convenient for external collaboration, but also means that managing an employee's account and managing links they distributed are separate responsibilities.

Choose a link's access requirements according to the information being shared and the relationship with its recipients. A public download, a password-protected delivery, and a delivery restricted to invited mailboxes establish different expectations about who can use the link and what its activity records tell you.

Choosing Recipient Requirements

A basic Share Link can be used by anyone who has its URL. Asking visitors to register records the details they enter; it does not verify that those details identify the person using the browser. Sending invitations associates activity with particular invitation URLs, but the invitation can still be forwarded.

Access Control requires an invitation and limits how its URL starts a browser session. A shared password adds a secret recipients must know. Email-based one-time passwords check access to an invited mailbox. Password protection and email-based one-time passwords are alternative settings; they cannot be enabled together on one Share Link.

Use email-based one-time passwords when mailbox verification is required. Use a password when a shared secret fits the delivery process. Neither a shared password nor access to a shared mailbox establishes a particular person's identity. If recipients need continuing, individually managed access with user-level controls, consider user accounts instead of treating a Share Link as an account substitute.

Ownership and Shared Content

A user needs Share permission on a folder to create links to its contents. A Share Link can belong to a user or a group. Every member of an owning group can manage that group's links, so adding a person to the group also delegates responsibility for its existing shares. Links created with a site-wide API key have no user owner and are managed by Site Administrators.

A link to live files follows changes to the shared content. New files added within its shared scope can become available through the existing link. A Snapshot Share Link instead delivers a fixed copy. Choose live sharing for an ongoing exchange and a snapshot when recipients should receive a particular version of a delivery.

The Share Link settings determine whether recipients can download, preview, or upload. A preview still displays file contents to the recipient, who can capture what they see. Removing a download button does not make visible information unreproducible.

Invitations and Identity

Each recipient receives a different invitation URL. Activity through that invitation is associated with the invited email address, including when someone else opens a forwarded copy. The address in the activity record identifies the invitation used; the invitation alone does not establish who is using the browser.

Email-based one-time passwords add a check that the visitor can obtain a code sent to the invited mailbox. This is useful when access must depend on control of that mailbox as well as possession of the invitation. A shared mailbox or a code passed to another person still does not establish an individual person's identity.

Invitation Reuse Across Browsers

With Access Control enabled, the browser that first opens an invitation establishes a session. Opening the same invitation in another browser, another device, or a private browsing session requires a replacement invitation. Files.com sends the replacement to the invited email address and invalidates the original invitation for new sessions. Replacement emails are limited to one per recipient per Share Link every 15 minutes.

The existing browser session keeps its access. Replacing an invitation changes how someone starts a session; it does not end sessions that already exist. Each recipient's invitation is handled independently, so opening one recipient's invitation does not invalidate another recipient's invitation.

For example, if Morgan forwards an unused invitation to Lee and Lee opens it first, Lee establishes the first session. Activity is associated with Morgan's invited address. When Morgan opens the same invitation in a different browser, Morgan needs the replacement sent to their mailbox. Requiring an email-based one-time password adds the mailbox check before Lee can access the share.

Expiration and Visitor Limits

Expiration sets the period during which a delivery remains available. Site settings can cap how far into the future a user sets a link's expiration; a shorter site-wide limit can also expire existing links. Snapshot Share Links have a maximum lifetime of 60 days. A publish date controls when access begins.

Visitor limits count browser sessions rather than verified individual people. One recipient using multiple browsers can consume multiple visits, while people using the same browser session are not separate identities. Use these limits to bound delivery activity, and use recipient requirements when you need to control who may receive the files.

Site-wide sharing controls have different effects on existing links. Disabling the creation of Share Links stops new links but leaves existing ones available. Requiring one-time passwords for new links does not add verification to previously created links. Review and revoke existing links separately when changing your sharing policy.

Changes to Existing Access

Enabling Access Control on an existing Share Link restricts new access without ending existing visitor sessions. To end access for all visitors, revoke the Share Link. A new Share Link can then use the required password or recipient restrictions.

Revocation cannot retrieve files already downloaded or content already loaded in a browser. File requests already authorized through temporary URLs also have their own expiration rules. Those limits are separate from the invitation and Share Link lifetimes.

Access When an Owner's Role Changes

Removing an owner's folder permissions does not revoke links they already created. Disabling or deleting the owner also leaves their links available by default so deliveries and shared business workflows can continue. The optional automatic-revocation setting applies when a user is disabled or deleted; it does not turn a folder-permission change into revocation.

An offboarding review therefore includes the person's links and any groups that own links, as well as their account. Share Link Ownership and Management explains how to retain a needed business delivery under suitable ownership or revoke a link whose purpose has ended.