Not every parent plan change should ripple downward. Not every child change should silently alter the parent view. Propagation rules give you precise control over how plan modifications flow through your hierarchy.
Why Propagation Rules Exist
In a flat OKR structure — where every KR is independent — a plan modification affects one plan and one plan only. The owner makes the change, the change is saved, and nothing else happens.
In a hierarchical structure, a single plan modification can trigger a chain reaction. A parent plan change might need to cascade to 5, 10, or 50 child plans. A child plan change might shift the aggregated parent view past a threshold that requires leadership attention. Without rules governing how these ripples propagate, you get one of two failure modes: uncontrolled cascades that blindside teams with unexpected plan changes, or silent misalignments where plans at different levels drift apart because changes don’t propagate at all.
Propagation rules sit between these two extremes. They define, for every parent-child relationship in the hierarchy, what happens when a plan is modified at either end: does the change cascade automatically? Does the other party need to review it? Or does the change stay local?
Propagation rules are the governance layer of hierarchical adaptive planning. They answer the question: when a plan changes at one level, who else needs to know, and how quickly?
The Two Directions of Propagation
Plan changes flow in two directions through the hierarchy, and each direction needs its own set of rules:
Direction 1: Parent → Child (Downward Propagation)
When a parent plan is modified, the change may need to cascade to child plans. This is the top-down direction: leadership adjusts the department target, and the teams beneath need updated allocations.
Profit.co offers three downward propagation rules:
| Rule | Behavior | Speed | Autonomy | Best For |
|---|---|---|---|---|
| Auto-cascade | Child plans are automatically recalculated to reflect the parent change. Child owners receive a notification after the change is applied. | Immediate | Low | Urgent changes where speed of alignment matters more than team input. Emergency pivots, board-mandated revisions. |
| Review-required | Child owners receive a notification with the proposed changes. They must accept, modify, or reject within 48 hours. The change is not applied until the owner acts. | 48 hours | Medium | The recommended default. Balances alignment speed with team ownership. Teams see what’s coming and can adapt. |
| Lock-down | The parent change does not cascade. Child plans remain as they were. Child owners are not notified. | N/A | Full | Intentionally decoupled plans. Mature teams managing their own targets independently. Experimental or exploratory KRs. |
Direction 2: Child → Parent (Upward Propagation)
When a child plan is modified, the parent’s aggregated view may change. This is the bottom-up direction: a team adjusts their plan based on ground-level data, and the department-level view shifts as a result.
Profit.co offers three upward propagation rules:
| Rule | Behavior | Signal Quality | Noise Level | Best For |
|---|---|---|---|---|
| Silent aggregation | The parent’s aggregated view updates in real time. No notification is sent to the parent owner. | Low | None | High-trust environments where minor plan adjustments are expected. Teams with frequent small modifications. |
| Threshold notification | The parent owner is notified when the aggregated total deviates from the parent target by more than a configurable percentage. | Medium | Low | The recommended default. Alerts leadership to material shifts while filtering out noise from minor adjustments. |
| Approval required | The child’s modification is held in a pending state until the parent owner approves it. The aggregated view does not update until approval. | High | High | Regulated environments, budget-sensitive plans, or situations where every change has compliance implications. |
The recommended default configuration for most organizations: review-required for downward propagation, threshold notification at 10% for upward propagation. This combination gives teams 48 hours to review cascaded changes from above, and alerts leadership only when bottom-up modifications are material enough to matter.
Configuring Rules by Relationship Type
Propagation rules don’t have to be the same for every parent-child pair. Different relationships in your hierarchy may warrant different rules based on the level of trust, the nature of the KR, and the organizational context.
| Relationship | Recommended Downward Rule | Recommended Upward Rule | Rationale |
|---|---|---|---|
| Company → Department | Review-required | Threshold at 10% | Department heads need to review strategic changes but shouldn’t be bottlenecked on every minor shift. |
| Department → Team | Review-required | Threshold at 15% | Teams are closer to execution and their plans change more frequently. A higher threshold reduces notification noise. |
| Team → Individual | Auto-cascade | Silent aggregation | Individual KRs typically mirror the team’s plan closely. Auto-cascade is efficient; silent aggregation avoids flooding the team lead. |
| Cross-functional parent → Multiple departments | Review-required | Threshold at 10% | Cross-functional cascades affect teams that may not share a direct reporting line. Review ensures each team has context. |
| Enterprise → Regional (multi-geo) | Review-required | Threshold at 10% | Regional teams operate semi-independently. They need to review global changes but may adapt them to local conditions. |
| Experimental KR → Contributing teams | Lock-down | Silent aggregation | Experimental KRs have high uncertainty. Cascading changes to contributing teams would create unnecessary churn. |
Setting the Threshold: How Much Change Is “Material”?
For threshold notification (the upward propagation rule), the critical configuration is the threshold percentage: how much must the aggregated bottom-up total deviate from the parent target before the parent owner is notified?
Set it too low, and leadership gets notifications for every minor adjustment — a 3% shift from a team reshaping their S-curve. Set it too high, and significant changes go unnoticed until the quarterly review.
| Threshold | Alert Frequency (est.) | Best For | Risk |
|---|---|---|---|
| 5% | 3–5 alerts per KR per quarter | Highly sensitive plans: board-visible KRs, financially material targets, compliance-driven metrics. | High noise. Leadership may start ignoring alerts. |
| 10% | 1–2 alerts per KR per quarter | Standard operating plans. The recommended default for most organizations. | Balanced. Catches material shifts without overwhelming. |
| 15% | 0–1 alert per KR per quarter | High-autonomy teams, experimental KRs, or organizations with very frequent plan modifications. | May miss gradual drift. A 12% cumulative gap grows slowly and stays below radar. |
| 20% | Rare alerts | Lock-down-lite. Leadership only wants to know about major shifts. | Risk of cascade drift going undetected for weeks. |
Start at 10%. After one quarter, review your alert history. If leadership received more than 3 alerts per parent KR, the threshold is too sensitive — raise it to 12–15%. If leadership received zero alerts but the QBR revealed significant gaps, the threshold was too high — lower it to 7–8%.
The Review-Required Workflow in Detail
Since review-required is the recommended default for downward propagation, it’s worth understanding exactly how it works in Profit.co:
What Triggers It
Any modification to a parent plan — whether manual, AI-generated, conversational command, or reconciliation-driven — triggers the review-required workflow for all child KRs with this rule configured.
What the Child Owner Sees
A notification appears in the child owner’s notification center and, if configured, as an email or Slack message. The notification includes the parent KR name, a summary of what changed in the parent plan, the proposed impact on the child plan (specific periods with before and after values), and the rationale from the parent’s check-in notes or AI command.
Three Response Options
Accept: The proposed changes are applied to the child plan as-is. A new audit trail entry is created: “Cascaded change accepted from [parent KR].” The child plan updates, and the parent’s aggregated view reflects the acceptance.
Modify: The child owner opens Modify Plan with the proposed values pre-loaded. They adjust the proposal to fit their local context — maybe shifting the cascade’s distribution to match a dependency timeline. A new audit trail entry captures both the original proposal and the owner’s modification.
Reject: The child plan remains unchanged. The parent owner is notified of the rejection with the child owner’s stated reason. The parent’s aggregated view reflects the gap between the proposed cascade and the actual child plan.
The 48-Hour Window
The child owner has 48 hours to respond. If no response is received within 48 hours, the system behavior depends on the organization’s configuration: either the proposed change is auto-applied (accept-by-default) or it remains pending and a reminder is sent (explicit-action-required). Most organizations choose accept-by-default to maintain the 72-Hour Rule’s discipline.
The 48-hour window is not negotiable within the framework. If a child owner needs more time to assess the impact, they should click Modify immediately (which stops the 48-hour clock) and take the time they need within the Modify Plan modal. The 48-hour constraint prevents indefinite pending states that block the parent’s aggregated view from reflecting reality.
Combining Rules: Mixed Configurations
Most hierarchies will use different propagation rules at different levels or for different types of KRs. Here’s how mixed configurations work in practice:
Example: Three-Level Hierarchy with Mixed Rules
Consider a hierarchy: CEO → VP Sales → Regional Directors → Account Executives.
CEO → VP Sales: Review-required down, threshold 10% up. The VP needs to review strategic changes. The CEO needs to know about material shifts.
VP Sales → Regional Directors: Review-required down, threshold 15% up. Directors are semi-independent; a slightly higher threshold reduces noise from regional adjustments.
Regional Directors → AEs: Auto-cascade down, silent aggregation up. AE plans closely mirror director plans. Auto-cascade is efficient. The director’s aggregated view updates silently.
When the CEO modifies the company revenue plan, the change cascades to the VP Sales (review-required, 48-hour window). The VP accepts and the change cascades to Regional Directors (review-required, another 48 hours). Directors accept and the change auto-cascades to AEs (immediate).
Total propagation time: under 96 hours from CEO modification to AE plan update. In practice, most acceptances happen within hours, not the full 48-hour window, so the typical end-to-end time is 24–48 hours.
Example: Same Level, Different Rules for Different KRs
Not every KR at the same hierarchy level needs the same rules. A director might have five child KRs:
Revenue KR: Review-required down, threshold 10% up. High financial materiality requires careful review.
Pipeline KR: Review-required down, threshold 15% up. Leading indicator; slightly more tolerance for variation.
Experimental channel KR: Lock-down down, silent aggregation up. Intentionally decoupled. The team is exploring and needs autonomy.
Profit.co supports per-KR rule configuration, so these mixed settings coexist within the same hierarchy level.
The Audit Trail for Propagation Events
Every propagation event — cascade, notification, acceptance, modification, rejection — is recorded in the audit trail. This creates a complete chain of evidence for how a change at one level affected plans at other levels.
A typical propagation audit chain looks like this:
| Timestamp | KR | Event | Detail |
|---|---|---|---|
| Mar 5, 2:47 PM | Company Revenue (parent) | Plan modified | AI command: “Reduce Q2 target to $4.7M. Back-load reduction into June.” |
| Mar 5, 2:47 PM | Sales Revenue (child) | Cascade proposed | Proposed: reduce allocation from $3.2M to $3.0M. Distribution proportionally adjusted. |
| Mar 5, 2:47 PM | Marketing Pipeline (child) | Cascade proposed | Proposed: reduce allocation from $1.5M to $1.4M. Distribution proportionally adjusted. |
| Mar 5, 4:12 PM | Sales Revenue | Cascade accepted | VP Sales accepted proposed changes. |
| Mar 5, 4:12 PM | North America Sales (grandchild) | Cascade proposed | Proposed: reduce NA allocation from $1.6M to $1.5M. |
| Mar 6, 9:30 AM | Marketing Pipeline | Cascade modified | Marketing VP modified: accepted $1.4M total but shifted reduction to June only (March–May unchanged). |
| Mar 6, 10:15 AM | North America Sales | Cascade accepted | NA Director accepted. Auto-cascaded to 6 AE plans. |
This audit chain shows exactly how the CEO’s modification on March 5 at 2:47 PM propagated to the NA Director’s acceptance on March 6 at 10:15 AM — a 19.5-hour propagation through three levels with one modification along the way. Every node in the chain is attributed, timestamped, and traceable.
When to Change Your Propagation Rules
Propagation rules are not set-and-forget. They should be reviewed and adjusted based on experience. Here are the signals that indicate a rule change is needed:
| Signal | Current Rule | Recommended Change |
|---|---|---|
| Leadership is overwhelmed with notifications. | Threshold at 5–7% | Raise to 10–15%. The threshold is too sensitive. |
| Significant gaps appear at QBR that weren’t flagged. | Threshold at 15–20% | Lower to 10%. The threshold is too permissive. |
| Teams feel blindsided by auto-cascaded changes. | Auto-cascade | Switch to review-required. Teams need a review window. |
| Review-required responses are always “Accept” with no modifications. | Review-required | Consider switching to auto-cascade. The review step is adding latency without adding value. |
| A team consistently rejects cascaded changes. | Review-required | Switch to lock-down for that team. Their plans may be intentionally decoupled from the parent. |
| Pending reviews are timing out (48h) frequently. | Review-required with 48h window | Switch to accept-by-default timeout, or shorten the window to 24h. |
| Approval-required is creating multi-day delays. | Approval required (upward) | Switch to threshold notification. Approval is too heavy for most modifications. |
Review your propagation rules at the end of each quarter as part of the adaptation review. Pull the notification and cascade data from the audit trail: how many notifications were sent? How many were acted on? How many cascades were accepted vs. modified vs. rejected? This data tells you whether the rules are calibrated correctly.
Setting Up Propagation Rules in Profit.co
Here’s the practical setup guide for configuring propagation rules:
Navigate to the parent KR in Profit.co. Open the KR settings or alignment configuration.
For each child KR relationship, set the downward propagation rule: auto-cascade, review-required, or lock-down.
Set the upward propagation rule for the parent: silent aggregation, threshold notification, or approval required. If using threshold, enter the percentage (recommended starting point: 10%).
Choose the timeout behavior for review-required: accept-by-default after 48 hours, or require explicit action (with reminder at 24 hours).
Test the configuration with a small modification. Make a minor change to the parent plan and verify that child owners receive the expected notification (or auto-cascade) within the expected timeframe.
Communicate the rules to all KR owners in the hierarchy. Every team should know: what happens when the parent plan changes, what happens when their plan changes, and what their response options are.
For first-time setup, configure all relationships at the same level with the same rules. Differentiate per-KR only after one quarter of experience tells you which KRs need different treatment. Starting uniform and evolving to mixed is easier than starting complex.
Rules Enable Freedom
It may seem paradoxical that adding rules to plan modification makes the organization more adaptive. But the paradox resolves when you consider the alternative: without rules, every plan modification triggers uncertainty. “Should I cascade this? Who should I notify? Does leadership need to know?” These questions consume time and mental energy, slowing the modification process and creating inconsistency.
Propagation rules eliminate these questions. The answers are pre-defined and automatic. The team making the modification doesn’t need to think about who else is affected — the system handles it. The parent owner doesn’t need to manually check whether the aggregated view has drifted — the threshold notification tells them. The child owner doesn’t need to guess whether a parent change affects them — the review prompt shows them exactly what’s proposed.
This automation of the governance layer is what makes adaptive planning sustainable at scale. Without it, plan modification is a manual, ad-hoc process that relies on human memory and good intentions. With it, plan modification is a systematic, auditable process that scales to any hierarchy depth.
Propagation rules are the invisible infrastructure of hierarchical adaptive planning. When they’re well-configured, nobody thinks about them — changes flow naturally, notifications arrive at the right time, and every level stays aligned. When they’re misconfigured, every modification becomes a coordination exercise. Get the rules right once, and the system takes care of the rest.
Configure once. Propagate automatically. Stay aligned at every level.
Profit.co’s propagation rules govern how plan changes flow through your hierarchy — auto-cascade for speed, review-required for autonomy, threshold notifications for signal quality. Start your free trial.