Parent-Child Feature: how does it work? – 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.

If you are considering Parent-Child vs Groups click here for comparison and explainer

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

How It Works

1. Account Structure

Parent Account (e.g., Acme Global)
├── Child 1 (Acme Chicago)
├── Child 2 (Acme NYC)
├── Child 3 (Acme London)
└── Child 4 (Acme LA)

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 (to collaborate, review, approve etc)

Limitations of parent access in child systems:

Cannot add users to child accounts
Cannot upload rate cards, clients and library data directly into child systems
Can only manage rate cards, clients and child library data by loading it at parent level and sharing down

Key Features in Detail

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

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 (exception - component hours)
Children can distinguish between their own data and parent data

User Management

Parent users can be added to child scopes for collaboration
Used to allow parent-level support or oversight on specific projects
Different from "Groups" feature (which enables collaboration across 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.

Known Limitations

Setup & Learning:

Takes time to learn the system
Configuration can be complex initially

User Management:

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

Permissions:

Limited granular permissions for parent users in child systems
Parent users can either access child system with their globally set privileges 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 Quantum) and inherited by child accounts, someone in parent account must manually share new data down to relevant children
No automatic distribution of new data

Groups vs. Parent-Child

Important distinction:

Parent-Child = organizational structure for managing multiple business units
Groups = collaboration feature for working across business units

Groups is a separate feature that works the same whether you're in a parent-child structure or not. It enables users from different business units to collaborate on specific projects.

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