Parent-Child & Groups: Explainer and comparison – Scope

What is Parent-Child?

Parent-Child is a feature that allows large companies, networks, or agency groups to manage multiple independent business units (child accounts) under one umbrella organization (parent account).

Think of it like this: A global agency network (e.g., Acme Global) is the parent, and each regional office or specialized agency (Acme Chicago, Acme London, Acme NYC) is a child.

What are Groups?

Groups is a separate collaboration feature that enables users from different ScopeBetter accounts to work together on shared projects, regardless of whether they're in a parent-child structure.

Think of it like this: Multiple agencies or teams form a temporary project team to collaborate on specific clients, sharing resources and working together across their different systems.

Parent-Child vs. Groups: Key Differences

Parent-Child	Groups
Hierarchical structure (parent → children)	Peer-to-peer collaboration
Top-down data sharing and control	Democratic sharing among equals
Parent decides what children receive	Group members collectively decide what to share
Permanent organizational structure	Flexible, project-based collaboration
Data is inherited and locked	Data is shared and collaborative
One-way flow (parent → child)	Two-way collaboration

Important: Groups works the same whether you're in a parent-child structure or not. They're independent features that can be used together or separately.

Why Use Parent-Child?

For the Parent Organization:

Single login access to view and manage all child systems
Centralized control of shared data like rate cards, clients, and service libraries
Consolidated reporting across all business units
Consistency in how clients are named and services are defined
Oversight without micromanagement—you can see what each child is doing

For Child Accounts:

Independence to operate with their own configurations
Access to pre-configured data from the parent (no need to set everything up from scratch)
Support from parent-level administrators
Faster implementation when parent shares core data sets

Why Use Groups?

For All Participants:

Cross-agency collaboration on specific clients or projects
Shared resources (service libraries, output templates, clients)
Unified workflows across different systems
Seamless scope collaboration with users from other agencies
Transparency about what's shared in vs. shared out
Flexibility to include external partners or sister agencies

How Parent-Child Works

1. Account Structure

Parent Account (e.g., Acme Global)
├── Child 1 (Acme US)
├── Child 2 (Acme Europe)
├── Child 3 (Acme UK)
└── Child 4 (Acme APAC)

2. Data Sharing

The parent can choose to share specific data with specific children:

What can be shared:

Rate cards
Clients
Services/deliverables
Output templates
Scope types
Disciplines

How sharing works:

Parent loads data at the parent level
Parent selects which children should receive each data set
When data is shared, it appears in the child's system but is locked (greyed out)
Children cannot edit inherited data—they must ask the parent to make changes
Children can also create their own independent data alongside inherited data

3. Parent Access

Parent users can:

Switch between child accounts using a dropdown menu
View all scopes created across all children
See which business unit created each scope
Access child systems to provide support
Be added as team members to specific child scopes

Limitations of parent access in child systems:

Can view scopes but not edit them (unless added as a team member)
Can add users, rate cards, and clients
Cannot upload library data directly into child systems
Can only manage child library data by loading it at parent level and sharing down

How Groups Work

1. Creating a Group

A host account (agency) initiates the group
The host invites users from their own account and/or other ScopeBetter accounts
Group settings determine what members can access and do

2. Group Management

Who can manage:

Group settings can be updated by any group member from any system
Members need appropriate permissions to edit group settings
Democratic approach—not just controlled by the host

What can be managed:

Which members are in the group
Group permissions and access levels
Shared resources (see below)

3. Shared Resources in Groups

Group members collectively select what to share:

Clients

Share specific clients that the group will work on together
Only scopes for shared clients can involve cross-system collaboration
Clear visibility of which clients are active in the group

Folder of Services (Library)

Share specific folders containing deliverables and components
All group members can:
- View shared deliverables and components
- Collaborate on developing them
- Use them when creating scopes in their own systems
Services can be used regardless of which system originally created them

Output Templates

Share output templates across all group members
Templates can be used in any scope across all systems
Works the same way as shared library services

4. Cross-System Scope Collaboration

This is where Groups becomes powerful:

How it works:

Agency A creates a scope for a shared client (client that's part of the group)
Agency A adds users from Agency B as:
- Collaborators (can edit)
- Reviewers (can review)
- Approvers (can approve)
Users from Agency B see the scope in their own system's scope list
Clear indicator shows the scope originated in Agency A's system
Agency B users can work on it according to their assigned role

Requirements:

The scope must be for a shared client (one that's been shared in the group)
Users must be group members
Users must have appropriate permissions

5. Visibility & Transparency

Groups provides clear indicators:

Shared Out: What you're sharing with the group
Shared In: What you're receiving from the group
Origin markers: Which system a scope or resource came from
Group badges: Visual indicators on shared items

Practical Examples

Example 1: Parent-Child in Action

Scenario: Cinema Global wants to ensure all child agencies use consistent rate cards and client names.

Setup:

Cinama Global (parent) loads all rate cards and clients at parent level
Parent assigns specific rate cards to each child:
- Cinema Italy gets Rate Card A, B, C
- Cinema France gets Rate Card B, C, D
Children see these rate cards (greyed out) and use them in scopes
When Cinema updates a rate card, all children automatically see the update

Result: Consistency across all agencies, no duplicate client names, centralized control.

Example 2: Groups in Action

Scenario: Three independent agencies (Agency A, B, and C) win a joint pitch for a major client and need to collaborate.

Setup:

Agency A (host) creates a group and invites users from Agency B and C
All three agencies share:
- The client (shared client)
- A folder of brand guidelines and deliverables (library folder)
- Standard output templates
Group members from all three agencies can now:
- See the shared client in their systems
- Use shared deliverables when scoping
- Collaborate on scopes for this client

Workflow:

Agency A creates a scope for the shared client
Adds Agency B users as collaborators and Agency C user as approver
Agency B users see the scope appear in their system's scope list
They can edit it from their own system
Agency C user approves from their system
Everyone uses the same shared library components

Result: Seamless collaboration without anyone leaving their own system, shared resources, unified client view.

Example 3: Parent-Child + Groups Together

Scenario: Acme Global (parent) has child agencies (Ireland, Spain, EMEA). Acme Ireland and a partner agency need to collaborate on a client project.

Parent-Child layer:

Acme Global shares rate cards and core clients down to all children
Acme Ireland inherits these and uses them

Groups layer:

Acme Ireland creates a group with the partner agency
They share:
- The specific client they're working on together
- Project-specific library folders
- Custom output templates
Users from both agencies collaborate on scopes

Result: Acme Ireland maintains its parent-child benefits (inherited rate cards, central control) while also collaborating externally with partners through groups.

Current Implementation

Groups Availability:

Available to all ScopeBetter accounts
Can be used independently or alongside parent-child
No special setup required, can be used immediately

Key Features in Detail

Parent-Child: Account Switcher

Parent users see a dropdown menu to switch between:

Parent account (global view)
Any child accounts they have access to

Note: Child users do NOT see this switcher—only parent users do

Parent-Child: Inherited Data Indicators

When a child account receives data from the parent:

Inherited items appear greyed out
Children can see the data but cannot modify it
Children can distinguish between their own data and parent data

Parent-Child: User Management

Parent users can be added to child scopes for collaboration
Used to allow parent-level support or oversight on specific projects

Groups: Shared In/Out Visibility

Group settings clearly show:

What resources you're sharing out to the group
What resources you're receiving (shared in) from the group
Origin of each shared item

Groups: Cross-System Scope Access

Scopes from other systems appear in your scope list
Clear visual indicator of which system created the scope
Filtered by shared clients—you only see relevant scopes
Work seamlessly as if it's your own scope

Groups: Democratic Management

Unlike parent-child (top-down), groups are collaborative
Any group member with permissions can update settings
All members have equal access to shared resources
No hierarchy—everyone works together

Known Limitations

Parent-Child Limitations:

Setup & Learning:

Takes time to learn the system
Configuration can be complex initially
Once learned, it makes sense and works well

User Management:

No consolidated user management across systems
Cannot move users between child accounts from parent level
When inviting users, you can't immediately assign which child accounts they access
Must wait for activation, then manually assign access

Permissions:

Limited granular permissions for parent users in child systems
Parent users can either see a child system or not—no middle ground
Cannot set specific permissions like "view only" or "edit scopes only"

Integration:

When feeds come into the parent (e.g., from CRM system), someone must manually share new data down to relevant children

Disciplines:

Important limitation: If the parent sets up disciplines, ALL children see ALL disciplines, even ones they don't use. There's no way to hide specific disciplines from specific children.

Groups Limitations:

Shared client requirement: Cross-system scope collaboration only works for shared clients
Manual setup: Each group requires manual configuration of shared resources
Dependency on group settings: If resources are removed from group sharing, access is lost
No inheritance: Unlike parent-child, there's no automatic cascade of updates

When to Use What

Use Parent-Child when:

You have a hierarchical organization structure (network, holding company)
You need centralized control over core data (rate cards, clients)
You want consolidated reporting across business units
You need consistency in naming and configurations
You have a dedicated parent administrator
Child agencies are part of your organization

Use Groups when:

You need to collaborate with external partners or sister agencies
You're working on joint client projects
You want to share specific resources for a project
You need peer-to-peer collaboration (no hierarchy)
You want flexible, temporary project teams
You need cross-system scope collaboration

Use Both when:

You have a parent-child structure AND need external collaboration
Internal agencies (children of parent) need to work with external partners
You want the benefits of centralized control (parent-child) plus flexible collaboration (groups)

Best Practices

Parent-Child Best Practices:

Designate a parent administrator who owns the parent-child structure
Centralize core data (rate cards, clients) at parent level for consistency
Define sharing rules clearly before rolling out to children
Train parent users on the switching mechanism and their access levels
Communicate with children about inherited vs. independent data
Plan for manual processes when integrations feed into the parent

Groups Best Practices:

Define group purpose clearly before inviting members
Select shared resources strategically—only share what's needed for the project
Set permissions appropriately for each member
Communicate expectations about who can edit group settings
Regularly review shared resources and remove what's no longer needed
Use clear naming conventions for shared folders and resources
Train group members on how to access and use shared resources

Quick Reference

Feature	Parent-Child	Groups
Structure	Hierarchical	Peer-to-peer
Control	Parent controls children	Collaborative
Data Flow	One-way (parent → child)	Two-way sharing
Permanence	Permanent structure	Flexible, project-based
External Collaboration	No	Yes
Use Case	Organizational management	Project collaboration
Data Editing	Inherited data locked	Shared data collaborative
Reporting	Consolidated parent view	Group-level visibility
Setup Complexity	Higher	Lower