Sharing with external collaborators

External sharing gives people outside your group — clients, contractors, stakeholders — scoped, read-only or lightly-editable access to a single dashboard page, a single item, or a filtered view, without giving them a member account or a seat.

Each share is a link (a capability URL). Anyone who can open the link and pass its gate sees exactly what the link is scoped to — never the rest of the group.

Plan requirement. External sharing is a Plus feature. On the Free tier the sharing section shows an upgrade prompt, and any existing links stop serving until the group is upgraded again. The instance operator can also disable the feature entirely (TIMILL_ENABLE_EXTERNAL_SHARING).

Where to manage sharing#

Group administrators (and anyone with the Manage sharing permission) find everything under Administration → External sharing:

• Share links — every link in the group, with its kind, access mode, health, target, expiry and visit count.
• Item type sharing rules — per-item-type configuration of what externals may see and do.
• Guest roster — the people who have verified their email on a link, with last-seen, links-used, notes and a revoke switch.
• Access log — an audit trail of every gate pass/failure and every external edit, with CSV export.

You can also start a link straight from where the content lives:

• Item view → the Share button in the header (an item that already has active links shows a green Shared externally chip instead).
• Item table (single type) → the Share view button, which pre-fills the current filter as a query link.
• Dashboard page → the Share button in the page title row.

The three kinds of link#

A view link always shows the live result of its query — items that stop matching disappear from the collaborator’s view, and (if you allow editing a field the query filters on) an external edit can move an item out of the shared view. That is usually what you want, e.g. a client closing their own tickets.

Access modes (how visitors pass the gate)#

Choose one when you create the link:

• Email verification (recommended, pre-selected). The visitor must receive a one-time 6-digit code at an allowed address. Possessing the URL is not enough. Leave the allow-lists empty to accept any address, or restrict to specific emails / domains.
• Password. The visitor needs the URL and a shared password you set.
• Public — anyone with the link. No verification at all. Use only when the content is safe for anyone who might ever receive the URL; the create dialog and the admin list flag public links distinctly.

Every link also has an expiry (30 days by default) and a guest session length, and can be revoked with one click — revocation takes effect on the very next request.

What externals can see and do — the item type rules#

For item and view links, what a collaborator sees is defined once per item type under Item type sharing rules — not on the link. Tightening a rule applies to every outstanding link of that type immediately.

Each rule controls:

• Enabled — the master switch. Item and view links of this type only serve while this is on.
• Visible fields — an allow-list, shown to externals in the order you arrange them (drag the handle to reorder). Nothing is visible unless you add it here.
• Editable fields — a subset of visible fields that externals may edit. Checking editable automatically marks a field visible. Leave all unchecked for read-only browsing.
• Comments / Attachments — whether externals can add comments or upload files.
• Defaults — the access mode, expiry and session length pre-filled when someone creates a link of this type.

Some fields can never be made editable externally (system fields, and user/assignee reference fields — editing those would expose your member roster). They show a — in the editable column.

Member names are visible. If you make a user, assignee or creator field visible — or if members comment on a shared item — external collaborators will see those members’ names. This is intentional for collaboration, but the field picker reminds you.

Security model, in plain words#

• The link is the only scope. A share request can only ever reach the group, item, page or query the link points at. There is no way to widen it from the outside.
• Deny by default. Externals start from zero visibility; everything shown or editable is something you explicitly added.
• Fail closed. A disabled, expired, revoked, plan-downgraded or feature-disabled link — and any unknown link — all return the same minimal “This link is unavailable” page, with no detail an attacker could learn from.
• No configuration access. Externals can never touch pages, layouts, queries, item types, roles, or the link itself, and can never delete or overwrite content.
• Auditable. Every gate pass, failure and edit is logged for 90 days. Failed-auth rows are highlighted in the access log, and you can export the whole trail as CSV.
• Abuse-bounded. One-time codes and passwords are rate-limited; write and upload volume is capped per session and per link+IP; public links require a proof-of-work check before their first write. The limits themselves are set on the server and are not adjustable from the app.

Kill switches, from narrow to broad#

1. Revoke a guest — blocks that person across every link in the group.
2. Disable a link — the toggle in the links table; the link goes dark on the next request.
3. Disable a type’s sharing rule — every item and view link of that type stops serving.
4. Operator: TIMILL_ENABLE_EXTERNAL_SHARING=false — every share request in the instance returns “unavailable”.

Reading the link health badge#

The links table shows each link’s health so you can spot problems at a glance:

• Active — serving normally.
• Expires soon — within 7 days of its expiry.
• Expired / Disabled — no longer serving.
• Blocked (plan) — the group is not on a plan that permits sharing.
• Target missing — the page, item, or type rule it points at was deleted or disabled.