Almanac
Microsoft/d365salesDynamics 365

Consultant-focused KB for Microsoft Dynamics 365 Sales: implementation notes, gotchas, and configuration decisions beyond the official docs — across pipeline management, opportunities, forecasting, sequences, sales accelerator, Copilot, integrations, administration, and licensing.

feature-forecast-adjustments.mdv1 · history
CurrentApplies to EnterpriseUpdated 6 days agoSource Microsoft Learn

What it does

Adjustments let a seller or manager type a different number over a calculated cell in the forecast grid, with a mandatory note explaining why. The adjusted value rolls up the hierarchy and the original calculated value stays visible alongside it. No opportunity is changed — the pipeline underneath is untouched.

Key facts

  • A column is only adjustable if Allow adjustments was set on it in the Layout step. Adjustable columns show a pencil icon on hover; everything else is read-only.
  • Three states per cell: calculated value (no adjustment anywhere), direct adjustment (you changed this cell) and indirect adjustment (someone above or below you in the hierarchy adjusted, and it has propagated into your row).
  • A note is mandatory when you adjust. The History tab on the adjustment dialog shows every adjustment and note for that cell.
  • Adjustments roll up to the parent record and onward up the hierarchy automatically. A manager adjusting their own total pushes the change down to direct reports' rows as indirect adjustments.
  • You can adjust your own rows and your direct reports' rows. You cannot adjust anyone above you in the hierarchy, regardless of security role.
  • Reset reverts a cell to the system-calculated value. It also requires a reason, records that reason in history, and rolls back the indirect adjustments that had propagated up the hierarchy.
  • You cannot directly overtype a cell that is showing an indirect adjustment — reset it to the calculated value first.
  • Recalculation does not overwrite adjusted values. Once adjusted, a cell holds its number until someone resets it or adjusts it again.
  • Adjustments made on the Forecasts page recalculate immediately, for current, past and annual periods alike. Adjust-field changes can still take up to two hours to appear everywhere.
  • A calculated column can be made adjustable only under strict conditions: addition and subtraction only in the formula, no adjustable columns, no Simple or Prediction columns, and no Hierarchy related columns in it.
  • Microsoft's own guidance is not to adjust stale opportunities (update the record instead) and not to adjust a deal to zero (close it as Lost).

When to use / skip

Turn adjustments on. A forecast that cannot be overridden is a pipeline report, and sales managers will maintain a parallel spreadsheet within a month — which is exactly the outcome you were hired to prevent.

The question is which columns. The usual answer is Committed and the total, and nothing else. Making Pipeline adjustable invites managers to inflate early-stage numbers rather than qualifying them. Making Won adjustable is indefensible.

Skip adjustments entirely only where forecasting feeds something contractual or compensation-related and the client's audit position requires the number to be purely system-derived. That is rare and usually a misunderstanding of what the forecast is for.

Be honest with clients about what adjustments cost: every adjusted cell is a place where the forecast diverges from CRM data, and the note field is the only audit trail. If nobody reads the notes, you have built a licence to make numbers up.

Configuration decisions

  • Which columns carry Allow adjustments — and get this agreed before you build calculated columns, because adjustable formulas lock their source columns out of being adjustable.
  • Whether adjustment happens at the seller level, manager level, or both. Both is the default behaviour of the hierarchy and it means adjustments compound.
  • Whether the total is the adjustable column or its components are. It cannot sensibly be both.
  • What the note field is expected to contain, and whether anyone reviews it as part of the forecast call.
  • Whether adjusted numbers or calculated numbers are the ones quoted upward to the board — the grid shows both and the client needs one answer.
  • Reset policy at period close: does the team clear adjustments each period or let history accumulate?

Gotchas

  • Indirect adjustments confuse people badly. A seller sees their number change without touching it, because their manager adjusted the team total. Explain this in training or you will field the ticket.
  • A manager adjusting the team total and a seller adjusting their own row are two different edits that interact. The order matters and the result is not always what either expected.
  • Adjustments survive recalculation, so an adjusted cell will not reflect a genuinely improved pipeline. Sellers who adjust upward in week one and then win the deal end up double-counting until someone resets.
  • You cannot make a source column adjustable retrospectively once it sits inside an adjustable calculated formula. This is a one-way door at design time.
  • Notes are mandatory but not validated. "adj" is a valid note.
  • Managers cannot adjust upward in the hierarchy, so a VP cannot fix a director's number directly — they have to ask. Clients with a top-down forecast culture find this restrictive.

Consultant notes

  • Demo the History tab, not just the pencil. The audit trail is what makes adjustments acceptable to finance.
  • Push back hard on making every column adjustable. It is the most common client request in this area and it produces a forecast nobody trusts.
  • Tell the client explicitly that adjusting does not change the opportunity, and that the two numbers will diverge. Some clients assume adjusting the forecast updates the deal.
  • Agree a reset cadence at go-live. Adjustments left in place across period boundaries are the main source of "the forecast is wrong" complaints in month two.
  • Before go-live, test an adjustment as a seller, then as their manager, and confirm both roll up as the client expects. Hierarchy behaviour is easier to demonstrate than to describe.

Worth another look if Microsoft adds approval or review workflow around adjustments, or opens up upward-hierarchy editing.

Was this accurate?