Sales Operations System
Users can be organised into teams, territories or a reporting line, and that structure can drive assignment, visibility and reporting.
A flat user list stops working the moment there is a manager. Rolling numbers up a hierarchy, routing by territory, and filtering a report to one team all depend on the structure existing as something the platform understands.
Yes where the platform provides both a grouping construct for users and a territory or hierarchy construct, and those structures drive assignment, visibility or reporting.
Partial where one exists without the other - teams but no territories, territories but no reporting line - or where the structure is a filter label rather than something assignment and roll-up run on.
No where the user list is flat and segmentation is achieved only by separating data into different workspaces.
Vendor material reachable during this evaluation covers user creation, system manager users and five security roles, but does not describe teams, territories or a reporting hierarchy as structures in the product.
Users are organised into groups, and a group is the unit that is granted access to a pipeline and that supplies the users a pipeline can assign deals to. That is a flat grouping used for permissions and deal routing. No manager-to-report hierarchy, territory model or rollup structure is documented.
Territories are user-defined and hierarchical, created with a name, a description and a parent territory, with sub-territories beneath them, and an opportunity carries a territory that also drives a left panel view. Employee roles are created by the administrator, grouping apps and setting access privileges per app at levels such as view or manage. Record visibility follows the management relationship, since a manager of an assigned employee can see that employee's records.
Teams group workspace members and are used both to assign access to objects, lists, workflows, dashboards and sequences, and as a filter across record views, list views, reports, the Calls page and workflow blocks. Members can belong to several teams, and deleting a team revokes the access it granted and breaks filters that referenced it. The number of teams a workspace may hold is governed by account limits. Teams are flat - no nesting or reporting hierarchy is documented - and there is no territory construct for geographic or account-segment assignment and routing. SCIM can provision users and teams from an identity provider.
Bigin has a role hierarchy. Roles are created with a Reports To superior and can be nested, and the vendor states that only users higher in the hierarchy can access the records of users below them, with an optional setting allowing users in the same role to see each other's data. Pipeline permissions can then be granted by role or profile. What is absent is a territory construct: no vendor article describes territories, territory assignment rules or territory based reporting, so the structure is a reporting line rather than a market segmentation.
An organisation sits above multiple workspaces, giving a two-tier structure with distinct role sets at each level, and members are added to the workspaces they need. Records carry owners and multiple owners can be assigned to one lead. There is no documented territory construct, no geographic or account-segment assignment and no routing, and no named sales team object beneath the workspace, so the capability is narrower than the dimension describes.
Teams group users to control record access, assign records and report on team performance, a user can belong to more than one team, and team is a reporting dimension in the pipeline and lost opportunity reports. The vendor names regional segmentation and franchise separation as uses of teams, but documents no nested team hierarchy and no dedicated territory object or assignment rules, so the structure is flat.
Groups collect users into named sets under Team Management and are usable as a filter across leads, opportunity reports and pipeline performance, so a manager can scope reporting to a team rather than the whole organisation. Vendor documentation describes no nesting of groups, no manager or reporting-line construct, and no territory object for geographic or account-segment assignment, so the structure is flat.
Teams can be created as groupings of users and used to scope record and report visibility and to grant access, create, edit and delete rights. Vendor documentation describes teams as flat groupings; no manager relationship, nested team hierarchy or territory construct with geographic or account-segment assignment is documented.
The workspace has three roles - owner, admin and member - which govern settings, billing and member administration, and collaboration beyond that is expressed by sharing individual groups with named people. There is no team object, no territory construct and no reporting hierarchy documented, and no way to roll figures up a management line.
All three structures exist and are distinct. Territories attach to records and drive data access scope; sales teams group users for reporting, task and meeting assignment and sequence sharing without changing access scope; and a user hierarchy assigns each user a reporting manager, renders an org chart, supports bulk assignment by import, and lets managers reach their reports' records.
Users can be grouped into teams that drive record visibility and report grouping, and teams can be nested under a parent team to form a hierarchy where a parent team sees what the teams below it own. Extra team members are excluded from team reports.
Teams exist as a grouping for assignment and visibility, and Advanced Permissions adds a role hierarchy in which a higher role can see records owned by roles reporting up to it, supplemented by sharing rules between peers. No territory management object is documented.
A User Teams capability is documented within roles and permissions but is restricted to one edition, and the documentation gives little detail on how it behaves. No territory object and no reporting hierarchy is documented.
Business units form the ownership boundary, owning teams and access teams group users, and a sales territory object holds a manager and members and supports parent-child territory hierarchies for geography, industry or product line. Access can additionally follow a manager hierarchy taken from the Manager field on the user record, or a separate position hierarchy that works across business units.
Teams are first-class - they are assigned in people columns, given ownership of boards, dashboards and workspaces, and used to grant column and board access - and sub-teams nest up to five levels to represent an organisational hierarchy. No territory concept is documented; geography is modelled as a column value and routed with round robin or lead assignment automations rather than as an ownership structure.
Administrators create groups of users and assign permissions at group level, which the vendor describes as creating a sense of hierarchy through individual or team permissions, and a user can belong to more than one group. Groups are the unit that records can be shared with. No reporting-line role hierarchy and no territory management structure are documented.
Users are grouped into teams, which drive visibility restrictions and can overlap. Territories are a first-class construct defined by country, state, city, postal code or phone area code, with an optional radius, applied automatically to companies and people by address, used to route leads to the responsible representative or team, to select a pipeline, and as a filter and report segment.
Teams can be created with a named manager, members and a description, and are usable as filters in pipeline, list and forecast views and as a dimension in Insights. Visibility groups can be nested into sub-groups to express a reporting hierarchy. No dedicated territory construct - geography or account-segment based assignment and routing - is documented, so the capability is present but narrower than the dimension describes.
Territories are defined in system settings and assigned to users in user management, with an optional restriction switch so an area manager can hold a territory without being limited by it. A user can be assigned only one territory, though many users can share one. Customer-side hierarchy is expressed through Company Groups with sub-companies. No user team object or reporting line between users is documented; managers see team output through dashboards and a user activity view rather than through a defined hierarchy.
The role hierarchy grants managers access to subordinates' records, opportunity and account teams give named colleagues access to specific records, and Enterprise Territory Management defines record access and ownership by territory.
A Streak team is a single flat group with three roles - Owner, Member and a billing-only role with no access to pipelines or contacts. Vendor documentation describes no sub-teams, groups, reporting hierarchy or territory construct; segmentation is achieved by creating separate pipelines and granting per-pipeline roles.
Users sit in roles, and roles form a hierarchy with subordinates. Groups collect members drawn from users, roles, groups, or a role together with all of its subordinates, and a group can be nested inside another group. Records are assigned to a group as well as to an individual, and sharing rules are written against roles, roles with subordinates and groups. Forecasts and quotas are also organised by team.
Three structures exist side by side: a role hierarchy that drives record access downward, user groups, and territory management, which groups accounts, contacts and deals by criteria such as geography, industry, product line or vertical and shares them with the sales staff assigned to that territory. Forecast targets can be set separately for each territory a user belongs to, and forecasts can be run on either the role hierarchy or the territory hierarchy.