Cortex supports fallback ownership only through entity hierarchies (ex: domains and their children). You cannot configure a “custom” fallback for other entity types, such as a team, to another outside of that hierarchy.
1. How fallback ownership works
Fallback owners are configured on parent entities (typically domains) and can be inherited by their children:
- You define owners on a domain using
x-cortex-ownerswithinheritance: FALLBACK. - If a child entity has no valid owners, Cortex assigns that fallback owner to the child.
- This mechanism is tied to the domain/entity hierarchy, not to other relationship types such as between teams themselves.
Because of this, you cannot:
- Set “Team A is a fallback for entities owned by Team B” if A and B are not related through a domain/entity hierarchy.
- Use fallback as a general “secondary owner” concept between unrelated teams.
Fallback is only evaluated when a child entity has no valid owners (including inherited APPEND owners). It is not a general-purpose secondary owner mechanism.
2. Primary vs. secondary owners
You can assign multiple owners (teams or users) to an entity via x-cortex-owners, but Cortex does not distinguish between “primary” and “secondary” owners in the ownership model today
- Fallback owners are used only when there are no valid owners at all; they are not treated as secondary owners alongside a primary owner.[
- There is no built-in notion of “secondary owners who can contribute but are distinct from the primary team."
4. Practical implications
- To use fallback, define it at the domain level so that unowned children can inherit ownership.
- For “secondary responsibility,” you can: Add additional teams as standard owners, or use descriptions or custom data to describe roles (ex: “Primary owner”, “Contributor”), understanding these are not treated differently in the ownership logic.