Parent and Child Organizations

Overview

Parent and child organizations help larger organization partners manage one public brand across multiple communities, regions, departments, or operating units.

The parent organization represents the shared public identity. Child organizations organize locations and content into the appropriate operating scope. A hierarchy can include more than one level, but the same rules apply from the lowest child to the top-level parent.

For example, a statewide organization might use one child organization for each community where it operates. Visitors still see the statewide brand, while each community shows only the locations and information that belong there.

Public Identity and Direct Ownership

Visitors generally see the top-level parent's name, logo, and brand styling when viewing a child organization or child-owned information. This creates a consistent public identity across the hierarchy.

Direct ownership remains separate from public identity. A location, article, event, challenge, or media item owned by a child organization remains owned by that child, even when it appears on the parent's public organization page.

In Manager, the organization switcher shows the direct organization you are working in. Always confirm the selected organization before creating or editing information.

Locations, Maps, and Statistics

Child-owned Areas, Trails, Outings, and Points of Interest roll up to parent organization pages. This lets a parent page represent the locations managed throughout its hierarchy without duplicating ownership records.

Community pages add an important boundary. A parent's organization page inside a community includes only locations that are both:

Owned or stewarded within the requested organization hierarchy.
Available in the current community.

Locations from sibling communities do not appear in that community's lists, maps, bounds, or statistics. Acreage, trail mileage, and location counts follow the same rule.

If both a child and its parent are listed as owners of the same location, public totals count the location once. The preferred long-term setup is to assign the most specific child organization as the direct owner and let the hierarchy provide parent visibility.

How Content Rolls Up

Content created by a child organization can appear in its parent organization's public context. This includes:

Articles and bulletin board items.
Events.
Images.
Documents and paper maps.
Web links.
Challenges.

The child organization remains the direct owner. The parent does not gain editing access merely because the content appears on its public page.

This behavior moves upward through the hierarchy. It does not automatically move downward. Content created only for a parent organization does not appear in every child organization or community unless it has an explicit reason to appear there.

Events, Alerts, and Closures

Events can reach a child or community when they are connected through a host organization, location, or other explicit attachment. A parent-owned event does not automatically appear in every child community.

Alerts and closures follow their selected targets and affected locations. Attaching an alert to a location makes it available in the organization and community contexts that include that location. An alert aimed only at a parent organization does not automatically notify every child or sibling community.

Use specific locations and targets whenever an update applies to only part of the hierarchy. This keeps information relevant and prevents an update for one region from appearing in another.

Challenges

Challenges combine organization ownership with task locations, so their scope requires extra care.

A child-owned challenge can appear on its parent organization's public page while remaining owned and editable by the child. When a challenge has task locations, those locations determine the communities where the challenge can appear.

A parent-owned challenge can reach a child community when its tasks are explicitly connected to locations available in that community. A parent challenge without task locations does not automatically appear in every child community.

When editing a child-owned challenge, use locations available to that child organization. If a challenge needs locations from a broader parent scope, create or own the challenge from the appropriate organization instead of relying on the public parent display.

Manager Access and Editing

Parent and child relationships do not grant inherited Manager access.

Parent team members do not automatically gain access to every child organization.
Child team members do not automatically gain access to the parent or sibling organizations.
Content remains editable only from the organization that directly owns it.
Public rollup does not turn inherited content into editable content in the parent's Manager workspace.

Content and media pages in a parent workspace can include two views:

Owned shows items directly owned by the selected organization. You can create and manage items according to your Manager role.
Inherited shows child-owned items that roll up to the selected organization. These items are read-only and identify their owning organization.

Inherited views are available for articles, Bulletin Board items, events, challenges, images, documents, paper maps, and other supported organization content. Social Outreach also identifies inherited child links separately from the selected organization's editable links.

If you are a member of the owning child organization, select an inherited item to open the owning workspace. If you are not a member, you can identify the owner but cannot open its Manager editor.

To edit child-owned information, switch to the child organization and make sure your Manager account has the required role there. Contact an Admin if you need access to another organization in the hierarchy.

What Does Not Happen Automatically

A parent and child relationship does not automatically:

Change the direct owner of a location or content item.
Copy content into another organization.
Give parent staff access to child workspaces.
Publish every parent item to every child community.
Include sibling-community locations in a community's map or statistics.

Use direct ownership, location attachments, hosts, targets, and other distribution controls to decide where information belongs.

Plan an Organization Hierarchy

Before setting up or changing a hierarchy:

Identify the organization that should provide the shared public name, logo, and brand.
Define child organizations around clear operating scopes, such as communities, regions, or departments.
Assign locations to the most specific organization that directly manages them.
Decide which team members need direct Manager access to each organization.
Review parent-owned events, alerts, closures, and challenges to make sure their locations and targets match the communities where they should appear.
Test a parent page in more than one community to confirm that maps, statistics, and content stay within the intended community.

Contact OuterSpatial support before restructuring an active hierarchy. We can help review ownership, team access, community membership, and content distribution so existing visitor experiences remain intact.