Guest Access
Work can be shared with somebody outside your organisation — a client, a referrer, a contractor. Guest access is the policy that decides what they may see and do. This page sets the space-wide boundary and the defaults, lists every share that exists, and individual shares then work inside it.
Where to find it
| Screen | Where it lives | What you need |
|---|---|---|
Guest access — /admin/guest-policy | Settings → Workspace & access → Guest access | Permission to read work items; saving the ceiling needs the settings manage permission |
| The guest share list — the same page | the section beneath the ceiling | crm.work_items.guest_shares.read opens it; which shares it answers with is one or more of the three permissions below; Revoke additionally needs permission to share work items |
Which guest shares somebody may see — three separate permissions
Opening the list and how much of it answers are two different decisions, and the second one is three separate permissions. Grant any mix of them; they add up.
| Permission | What the list then shows |
|---|---|
crm.work_items.guest_shares.read.own | the shares you made — the ones your own login created. A share made by an automation has no person behind it and is nobody's own |
crm.work_items.guest_shares.read.assigned | every share on a work item assigned to you, whoever made it |
crm.work_items.guest_shares.read.all | every share on every work item you can see |
crm.work_items.guest_shares.read.managed | reserved. "The shares of the people you manage" waits for team managers; granting it today changes no answer |
Two rules apply at every one of those levels, including the widest:
- Only for work items you are allowed to see. A member without See everyone’s work items, not just my own sees only items assigned to them, so even
…read.allthen means "every share on my own items". The list says so in words under its heading. - The heading tells you which level you are reading at, and names the permission that would widen it. A short list is never a silent one.
A group that can open the list but holds none of the three gets an empty list that says why — and the permission-group editor says so while you are composing it, under Guest shares this group can see.
These three permissions bind the per-item share list too — the Share with… section of a work item. Being allowed to read an item does not by itself show who it is shared with. A colleague who may share an item but holds no level key is told, in that section, that there may be shares they cannot see, so an empty list is never read as "nobody has shared this". Sharing is not a way around that: re-sharing an item with a person who already has a share the colleague cannot see is refused in words, and nothing is written — someone who can see that share has to change it.
Nor is sharing a way around the work-item fence. Sharing, ending a share (Revoke) and copying a share's link all need permission to read work items as well as permission to share them — the share permission alone opens nothing — and a work item you are not allowed to see cannot be shared by you: naming it answers the same plain Not found every other screen gives you for it, and says nothing about whether it exists or is already shared. Revoke and Copy link act only on a share you are allowed to see: a share your guest-share permissions hide answers the same plain Not found as a share that does not exist, and nothing is ended and no link is made. Two people sharing the same item with the same person at the same moment never overwrite each other either: whichever share is written first stands, and the other is refused in words. The same holds when a share you can see is changed by somebody else — or ended, or newly made — between the moment you looked at it and the moment you save: the Share with… section sends the share it showed you along with your save, your save is refused in words that say so (…or that share has changed since you looked), nothing of theirs is overwritten, and you look again (close and reopen the item) before you try once more. A program that calls the share door directly without saying what it looked at gets only the narrower check: a share changed in the instant between the door's own read and its write is refused, and otherwise its save replaces a share it is allowed to see.
The one rule
Individual shares can narrow these choices, never exceed them — and the ceiling binds every time a share is used, not only when it was saved.
So this page is a ceiling, in the same sense as a space's permission ceiling, and it binds in two places:
- When a share is saved. Every action it asks for is checked against the set on this page, and a share that asks for more is refused outright with the words guest verb policy ceiling refuses.
- Every time a guest uses their link. What the guest actually gets is the share's own actions cut down to the set on this page as it stands at that moment. Narrow the ceiling and every share in the space — including ones handed out months ago — loses what you removed, at once, with nothing else to do.
Narrowing never rewrites a share. The share keeps exactly the actions it was given; the ceiling simply stops allowing some of them. So if you narrow the ceiling and then widen it back, every share is restored to what it was, untouched. That is also why the list below can show you a share that is wider than the ceiling: the share still says what it was given, and the ceiling says what of that is live.
What you set
| Setting | What it means |
|---|---|
| Grantable verb ceiling | the complete set of actions any share may ever grant a guest. Nothing outside this set is available to any share in this space, and anything you take out of it stops working on every existing share immediately |
| Default access mode | what a new share starts at — View only, or Edit through granted verbs |
| Default sub-item ladder | how much of what nests under a shared item a guest sees by default — Hidden, Count only (locked), or All sub-items |
The two access modes
The mode decides what a guest may do with the item that was shared with them. There are exactly two:
| Mode | What a guest may do |
|---|---|
| View only | read the item — nothing else |
| Edit through granted verbs | read the item — the actions the share granted it from the verb ceiling above are recorded, but see the note below |
Today the guest link is read-only in either mode. The only thing a guest can open is the shared-item page, and that page reads — it offers no action to take. Each share stores its own mode and actions; today they change nothing a guest can do.
The mode does not hide anything either way. What decides whether a guest sees the shared item at all is the View action: the link shows the item only if the share's actions still include View after the ceiling has cut them down, and otherwise it answers a plain Not found — the same answer a share that was never given View has always given. The share form ticks View by default while the ceiling on this page allows View. If you turn View off in the ceiling here, every link in the space answers Not found — the ones already handed out as well as any saved afterwards — and turning View back on makes them all work again. Hiding beyond that is the job of the ladder below, and of the guest-visible field list further down this page.
The sub-item ladder
Work items nest, so sharing one raises the question of how deep the share goes. The default ladder answers it once, for the whole space, instead of leaving it to each share. It has three rungs:
| Rung | What a guest sees beneath the shared item |
|---|---|
| Hidden | nothing, and no hint that anything nests underneath |
| Count only (locked) | that sub-items exist, and how many, as a locked count with no detail |
| All sub-items | the sub-items themselves |
Count only (locked) is the rung worth knowing about: it lets a guest see that there is work going on underneath without seeing any of it. It is often the honest answer when a client should know a case is progressing but not read its parts.
Both of these are starting points only. Each share stores its own rung and mode: the Share with… section of a work item's drawer lists every share of that item as rung · mode · actions — striking through any action the current ceiling no longer allows — and the form beneath it sets them per share.
Where that form starts. A work item type carries its own guest mode and ladder defaults, and the share form for an item of that type starts from the type's; the defaults on this page answer where a type has none. So a type whose work is always client-facing can start its shares at All sub-items without changing the space.
Worth knowing: today every type has a mode and a rung of its own — a type you have never edited reads Hidden and View only — so for an item it is always the type that decides where the form starts, and the two defaults on this page are what answers where no particular item is in play. If you want every share in the space to start somewhere else, set it on the types, not here.
Shares in this space
Beneath the ceiling, this page lists every guest share in the space — one row per share, so you never have to open work items one at a time to find out who holds what:
| Column | What it tells you |
|---|---|
| Work item / Shared with | which item is shared, and with which outside person |
| Sub-items / Mode | that share's own rung and mode — its own, not the space's defaults |
| Actions | the actions the share was given. An action the current ceiling no longer allows is struck through, and the row is marked wider than the ceiling. A share whose View has been cut away also says its link answers Not found |
| Created | when the share was made |
| Revoke | ends the share and stops its link working at once |
A count above the table says how many shares in this list are wider than the ceiling right now, so after narrowing the ceiling you can see at a glance whether anything was affected. The count is over the list you are actually being shown, never over the whole space — at a narrower level it is a smaller number, and the words say so. Opening this list is its own permission (crm.work_items.guest_shares.read), which shares it answers with is the three permissions above, and it only shows either way: Revoke needs permission to share work items, and changing the ceiling needs the settings manage permission.
Which fields a guest can see
The mode above records whether a guest may only read the shared item or also act on it, and the ladder decides how much of what nests underneath they see. Which fields on the item a guest may read is set per work item type, and it is deny by default: a field or section an outside person may see needs an explicit row. That list lives with the type — see Work Items.