Sales Operations System
Visibility and editing can be controlled for individual records, so a user sees only what they should.
This matters as soon as a team has more than one salesperson, competing territories, or confidential customers. Object-level access is all or nothing, which forces a choice between over-exposing data and blocking people from doing their job.
Yes where visibility or editing can be set on an individual record, or where a documented sharing model scopes records to owners, groups or teams.
Partial where the only controls are account-wide switches on the user - a territory restriction, an owner-only restriction - rather than anything set on the record itself.
No where access is granted per object and applies to every record in it.
Assigning an owner is not a visibility control. Ownership records responsibility; it does not restrict who can see the record.
The vendor's security and privacy paper lists record-level access, controlling access to specific entities, as a configurable control, alongside five security roles that govern what actions a user may perform.
Access is controlled per pipeline: when a pipeline is created or edited, the groups that may access it are selected and any group left out is shut out, which restricts a whole set of deals rather than an individual record. User group permissions themselves are set at feature level, covering deals, accounts, contacts and the rest, and no per-record or owner-only visibility rule is documented.
Data level access is set per app, either all employees see all records or employees see only records assigned to them, in which case visibility extends to the assigned employee, that employee's managers and any users listed as exceptions. Beyond that, data sets group records by field criteria, for example opportunities where the assigned team matches a chosen value, and data access sets grant a named employee access to a given data set.
Access is granted per object - full access, read and write, or read only - and can be set for the whole workspace, for teams, for individual members and for workflows, with the most permissive applicable setting winning. That grant applies to every record in the object. Lists carry the same four-level model applied to the whole list, and once a member has read and write access to a list they can create, update and delete any entry in it. Vendor documentation describes no mechanism for restricting an individual record or list entry to a subset of users.
Access is controlled at two levels. A profile sets view, create, edit and delete permission per module and governs which Team Pipelines a user reaches. Within a pipeline, six permission levels apply - organiser, manager, member, participant, viewer and requester - and they differ by record scope: a member can view all records in the pipeline but edit or delete only records they own, a participant sees only their own records, a viewer has read access to all records, and a requester reaches only records they created. Where role hierarchy is enabled, a superior additionally sees subordinates' records.
Permissions operate at two tiers, organisation and workspace. Organisation roles cover owner, admin and member and govern which workspaces a person can reach; workspace roles cover owner, admin, manager, member and guest and govern billing, member management, settings and workspace deletion, with guest being read-only across the whole workspace. Records carry owners, which is assignment rather than restriction, and no per-record visibility setting is documented. Separating data between teams is achieved by putting it in different workspaces.
A Restricted User can only reach records assigned to themselves and cannot see unassigned records. Teams provide the other lever: records assigned to a team are visible to that team's members, and a user's default team is applied automatically to records they create. The constraint the vendor names is that a record assigned only to an owner with no team remains visible to all standard users.
Lead Visibility is configured on a custom role by enabling limited visibility and nominating up to three fields that decide which leads the role can reach, most commonly Lead Owner, with an option to also expose unassigned leads. The restriction applies across the application including search, reports, opportunities and pipelines, an unauthorised lead returns a blocked page, and each lead shows a visibility summary of which users and roles can see it. Inbox items are documented as not filtered by lead visibility.
People, company and opportunity records carry a Visibility setting offering everyone, a named team, named individuals, the record owner only, or only the creator. Team-level permissions can additionally scope a team to records owned by anyone, by team members, or by the user alone, with separate access, create, edit and delete rights. Account owners and administrators see all records regardless of the setting.
Access to contacts and deals is governed at the group level, not per record. A group is private, shared with selected members, or shared with everyone, and each member is given owner, full access, can edit or can view. One object does carry a genuine per-record control: a task is set public or private individually. Interaction visibility is configured per user and per connected email account - private, subject only, or full access - rather than on the individual interaction.
Roles carry record access scopes of All Records, Territory Only / Group Only, or Owned Only, set independently for the view, edit and delete actions on contacts, accounts, deals and custom modules. The vendor gives the example of granting view access to all records while restricting edit access to records the user owns.
CRM object permissions scope view, edit, delete and merge to All records, Their team's records or Their records, with an option to include unassigned records. Users limited to their own records see only those records on index pages, in segments and in reports. Individual records can also be shared with named users and teams.
Under Simple Permissions each record carries a visibility setting granting named users or teams access to that record. Under Advanced Permissions per-record sharing is replaced by ownership, role hierarchy, organisation-wide defaults and sharing rules, so access is still controlled at record level but by rule rather than case by case.
Permissions are grouped by category and assigned to roles, and the supplied Staff role is documented as limiting a user to viewing only their own contacts, their own tasks and the deals assigned to them. Roles can be added, edited and deleted.
Individual rows can be shared with named users or teams as an exception to role and business unit access, with the share carrying specific privileges, and access teams apply the same mechanism from a template. Security roles grant Create, Read, Write, Delete, Append, Append To, Assign and Share privileges scoped by ownership, and the hierarchy security model gives managers or higher positions read/write access to direct reports' records and read-only access further down, bounded by a depth setting.
Board permission sets include an option limiting non-owners to viewing the board and editing only the items assigned to them through a nominated people column, and a further board permission level adds a view restriction so a user sees only items they created or are assigned to. Control is by role plus assignment on a board, not per-record sharing rules, and board owners are exempt.
An individual deal carries one of four privacy settings - private to the owner, shared with everyone, viewable to everyone, or custom privacy granting named people or groups specific access. Contacts have an equivalent privacy feature, and an administrator delegates the right to view or edit private deals through privacy settings.
Non-administrators can be restricted to seeing all data, only their team's data, or only their own data, with the most restrictive setting applying where a user sits on several teams. Separately, a pipeline's visibility can be limited to named users or teams, in which case its leads do not appear in excluded users' lists, reports or dashboards, though a user assigned to a lead can always see that lead.
Visibility groups, with sub-groups where the account allows them, control which users can see which records. Individual items - deals, leads, persons, organisations and products - carry a visible-to setting offering owner only, the owner's visibility group, the owner's group and its sub-groups, or all users.
Two visibility restrictions are documented. A territory restriction limits a user to seeing only Companies within their assigned territory, and an Account Manager restriction limits a user to records they are the account manager of. Both are switches on the user rather than a per-record visibility setting, and there is no documented mechanism for setting visibility on an individual record.
Record access is set by organisation-wide defaults per object and then widened by role hierarchy, sharing rules, manual sharing, teams, territories and queues, and narrowed again by restriction rules.
Access is set per pipeline through six roles. Admin and Editor see and edit every box; Creator sees every box but edits only those assigned to them; Assignee views and edits only assigned boxes; Viewer sees every box read-only; Observer sees only assigned boxes. Assignment therefore scopes visibility and editing at the individual record level, and pipeline permissions operate independently of team-level roles.
Access to records is governed by custom sharing rules. A sharing rule can grant a group sight of the records belonging to a role, to a role and its subordinates, or to another group, and records are assigned to users or to groups. Sharing rules also apply to the calendar, where event visibility can be set so that other users see only that a slot is busy.
Each module carries a default organisation-wide setting of private, public read only, public read/write or public read/write/delete, and the role hierarchy gives a superior access to a subordinate's records. Sharing rules extend access by record owner role or group, or by field criteria, at read only, read/write or read/write/delete. Individual records can also be shared manually with named users, roles or groups at read only, read/write or full access, subject to the module's default setting being restrictive and to the subscription in use; activity records cannot be shared directly because they follow their parent.