Child organizations in CloudBees Unify inherit some configuration from their parent organization, and the rules differ by capability. Use this reference when you design an organization hierarchy, or when a child organization doesn’t have a resource you expect it to have.
General rules
The following rules apply to every capability that supports inheritance:
-
Inheritance flows from a parent organization to its children and their descendants, never upward.
-
Sibling organizations don’t inherit from each other.
-
Inheritance is additive. A child organization can use inherited resources and also define its own.
Refer to Inheritance and override principles for the concepts behind these rules.
Inheritance by capability
The following table lists whether each capability is inherited by child organizations, and whether a child organization can override what it inherits. Notifications don’t fit this pattern; refer to its row for how they actually work across the hierarchy.
| Capability | Inherited | Override in child organization | Details |
|---|---|---|---|
Properties and secrets |
Yes |
Yes, unless the parent selects Prevent override. |
Inherited properties can’t be edited or deleted in the child organization. Refer to Manage properties and secrets. |
Yes |
No. Create a separate environment in the child organization instead. |
Organization-owned environments appear in all components. Inherited environments can’t be modified or deleted at the component level. Refer to Understanding environments. |
|
Yes |
No. Create a separate integration in the child organization instead. |
Refer to Organizational scoping and inheritance. |
|
Yes |
No. Create a separate container in the child organization instead. |
Refer to Configure containers. |
|
Yes |
No. Create a separate preconfigured action in the child organization instead. |
Refer to Set up preconfigured actions. |
|
Not applicable |
Not applicable |
A notification created on an organization covers events in that organization and in all of its descendants. This is different from resource inheritance: a child organization doesn’t gain a copy of the configuration, and can’t view, edit, or remove a notification created on an ancestor. Refer to Configure notifications. |
|
Yes |
No. Inheritance can’t be blocked for a specific child organization. |
Permissions are granted to users and teams on an organization and apply in all of its descendants. Roles granted on a child organization combine with inherited roles. Refer to Understanding role-based access control. |
|
Security tools |
Yes |
Yes. Below the root organization, a change creates an override record, and later changes to the parent don’t affect that organization. |
Deactivating a tool on the root organization disables it for all child organizations, regardless of override records. For tools that require an integration, the configuration can be set to allow or prevent inheritance. Refer to Organizational hierarchy and inheritance. |
Security SLAs |
Yes |
Yes, unless the parent selects Prevent override. |
When a parent prevents overrides, child organizations revert to the parent’s SLA settings, and existing overrides are kept but inactive. Refer to Manage SLA inheritance. |
Feature management entities |
No |
Not applicable |
Flags, applications, target groups, and other feature management entities are scoped to the organization where they’re created. They haven’t been inherited since Release 1.60. Refer to Feature management organization scope and inheritance. |