Sharing & Security

Sharing answers the question: "Which records can this user see and edit?" Four layers stack together to give the answer:

1. Object permissions — may this user touch this object at all? (See Profiles.)
2. Org-Wide Defaults (OWD) — the record-level baseline ("opportunities are private").
3. Sharing Rules — the openings ("the EU team can edit EU accounts").
4. Manual shares — record-level "you're working this one with me".

Plus Field-Level Security for masking sensitive fields inside a record the user can see.

The first layer is a gate, not a filter. If a profile does not grant the object, no OWD, sharing rule or View All setting can put those records back — the request is refused before sharing is ever consulted.

Layer 1 — Org-Wide Defaults

OWD is the most restrictive setting for each object. Everything else widens it.

Options for OWD: Private / Public Read-Only / Public Read/Write / Controlled by Parent.

Controlled by Parent, in practice

For the six parent-derived objects above, there is nothing to configure per user: access is computed.

• Read — you see the rows whose parent you can see, and "can see" means every route that would let you open the parent directly: you own it, a sharing rule granted it, or someone shared it with you by hand. Measured against the shipped stack (platform 17.0.0-rc.4): a rep who can read exactly one account reads that account's contacts and no others, and a rep who can read no quote reads no quote line items at all. The account reaching that rep only through a territory rule is the point — a parent held by a share counts as a parent you can see.
• Write — adding, changing or removing a row requires edit access to the parent, resolved the same way as reads. A row under a parent you cannot edit is refused, naming the parent that stopped it.

This changed in platform 17.0.0-rc.4. Through 17.0.0-rc.3 the computed answer was org-wide rather than parent-scoped: the derivation resolved accessible parents from the parent object's row-level security policies alone, and HotCRM authors almost none, so a Controlled by Parent object was readable — and writable — by every user whose profile granted the object at all. If you are running an earlier release, that is the behaviour you have, and quote and opportunity line pricing is visible org-wide. The repo test test/parent-derived-reach.test.ts pins the current reach in both directions (#549, #694; upstream fix objectstack-ai/objectstack#5386).

Because access is derived, ownership of the child row is irrelevant — a quote line the quote-generation flow created is as visible to the quote's owner as one they typed themselves.

Layer 2 — Positions

A position is a flat group used to distribute access. HotCRM ships twelve:

executive
sales_director      sales_manager      sales_rep
service_director    service_manager    service_agent
marketing_director  marketing_manager  marketing_user
na_sales_team       eu_sales_team          (territory groupings)

Positions are flat by design — there is no hierarchy and nothing rolls up. A sales director does not inherit a sales manager's access; each rung that needs a record is named by its own sharing rule. That is why several rules below come in pairs.

Assign positions in Setup → Users; a user may hold more than one.

Layer 3 — Sharing Rules

Sharing rules open up record access beyond the OWD baseline.

Two flavours

Criteria-based rules are the enforced flavour: matching records materialise real share grants.

Built-in sharing rules

Create your own in Setup → Sharing Rules.

Criteria filter on plain fields, never on part of an Address. The two territory rules match on the account's Billing Country — a read-only two-letter code derived from the country you type into Billing Address — and not on the address itself. A criteria rule has to run as a database query, and a query cannot reach inside a structured Address or Location value. A rule written against Billing Address → Country is therefore rejected outright rather than quietly widened to "every account": it is never installed, and the position it names receives nothing. Nothing in the UI marks such a rule as broken, so when a team reports missing records, check that every field the rule names is a plain field on the object.

A rule widens one object, not the records underneath it

Sharing rules are authored per object. Widening Account widens accounts — the records hanging off a shared account keep their own baseline, and Contact is the only one derived from it:

So a territory rule hands over the account record; the deal, quote, contract, case, task and meeting history underneath stays with its owners, and those related lists can look empty or partial on an account the user can otherwise read in full. Contacts are the exception, and the intended one: they follow the account, so the Contacts list of a territory-shared account is complete.

Making a child object follow the account is a deliberate widening, not a config detail. A sharing rule on the child object with criteria matching the account rules opens that object for every holder of it, not only for the territory recipients. Setting the child's OWD to Controlled by Parent is the narrower instrument: since platform 17.0.0-rc.4 it grants the child exactly to whoever can reach the parent (see Controlled by Parent, in practice above). HotCRM ships neither for Quote and Contract today; whether it should is an open decision (#549).

Layer 4 — Manual shares

A manual share grants one user or group Read or Read/Write on a single record, on top of everything above. Shares live per record. Since platform 17.0.0-rc.4 a manual share also carries the parent-derived children of that record: sharing an account hands over its contacts, because the derivation resolves the parent through share grants like any other route (see Controlled by Parent, in practice).

HotCRM ships no account-team object — there is no team roster on the account and no Team tab. The rule named Account Team Sharing in the table above is an ordinary criteria rule: it gives every sales_manager edit on active customer accounts, not a per-record pod. An org that sells in pods models the pod as a position with its own sharing rule, or as manual shares on the account.

How the layers combine

A user sees a record when all of the following hold: their profile grants read on the object, and any of these is true:

1. They own the record.
2. Their profile grants View All on the object.
3. The OWD is Public Read-Only or wider.
4. The object is Controlled by Parent and its parent is visible to them by any of these same routes (see Controlled by Parent, in practice).
5. A sharing rule matches the record and one of their positions.
6. The record was shared manually with them.

If none apply, the record is simply gone from lists, search and reports — not an error message.

Ownership and transfers

Every record has exactly one Owner. It is the field on the form, the one the "My …" views filter on, and the one every rule above means by "the record's owner" — one column, one answer. Reassigning Owner really does hand the record over: the previous owner loses their owner-based access and the new one gains it, immediately and everywhere.

Because it moves access, changing Owner is a permission of its own, separate from ordinary edit rights:

Three everyday actions are not transfers and need no such permission:

• Creating a record. New records are stamped to their creator automatically — you never pick yourself.
• Saving a form without touching Owner, even though the form submits the field.
• Automation acting on your behalf — the round-robin that routes an incoming lead, the nightly sweeps that book renewal and follow-up tasks.

A user without the permission who tries to reassign gets a clear refusal rather than a silent no-op. If you need to move a book of business, ask an administrator or your sales manager.

Upgrading from an earlier release? Owner used to be an ordinary field that anyone with edit rights could change — and changing it moved the record in every list and report while moving no access at all. The two are now the same field. Records whose displayed Owner had drifted away from their real access owner need a one-time pass to bring them back into line; see the release notes for the backfill.

Private opportunities

Private on an opportunity is enforced on top of everything above: a deal a user flags Private stays visible to its owner (and to administrators) only, even for profiles that otherwise hold org-wide opportunity read, such as Sales Manager and Marketing User. Use it for board-level or acquisition-sensitive deals.

Field-Level Security (FLS)

FLS controls which fields inside a visible record a profile can see and edit — for example account health score is readable to everyone who can see the account but only the sales manager sets it, and case internal notes are hidden from sales reps entirely. The shipped masks are listed in Profiles.

FLS is enforced everywhere — list views, reports, the API and the AI Copilot. A masked field also cannot be used as a filter, sort or grouping.

Sharing for the AI Copilot

The Copilot acts on behalf of the user — it sees exactly what the user sees, no more:

• Object permissions, sharing and FLS all apply automatically.
• An admin running the Copilot will see more than a rep — by design.

There is no "AI bypass".

Tips for admins

• ✅ Check the object grant first. An empty related list or a nav item that errors is nearly always a missing object permission, not a sharing problem.
• ✅ Start restrictive — Private OWD on Lead / Account / Opportunity, then open up with sharing rules.
• ✅ Remember positions are flat. Granting the manager does not grant the director; author both.
• ✅ Audit sharing rules quarterly — they accumulate.
• ✅ Don't over-use View All — it's a sledgehammer that bypasses every sharing rule.

Tips for users

If you think you should be able to see a record and can't:

1. Check who owns it.
2. If you reached it from an account, check which object it is: quotes, contracts, tasks, cases and deals stay with their owner even when the account itself is shared with you. Contacts are the one related list that is never withheld — Contact is Controlled by Parent, so it follows the account and arrives with it (see Controlled by Parent, in practice).
3. Check whether the deal is flagged Private.
4. Ask your admin whether a sharing rule should cover your position.