Gong changes forecast submission semantics for future fiscal periods

What Gong is changing

Gong published a Data Cloud change notice on September 17 for its FORECAST_SUBMISSIONS and FORECAST_SUBMISSIONS_HISTORY tables. Gong says the WEEK field will support negative integers when a submission is made before the forecast period begins. If the period is a quarter, for example, a negative value represents how many weeks before that quarter the submission was made. Active-period submissions continue to use positive WEEK values.

Gong says the change takes effect on October 14, 2026 and may affect queries, filters, reports or dashboards that use forecast submission data. The notice also says multiple future-period submissions can now be stored separately, so teams may see more rows for a fiscal period than they did under the earlier behavior. The change is documented for Data Cloud users and is explicitly aimed at forecast submission history rather than a generic CRM field.

Sources: Gong Data Cloud change notice, September 17, 2026

Why a signed week value is a data-contract change

A field can keep the same name and data type while still changing its operational meaning. A model that previously treated WEEK as a positive sequence may contain filters such as WEEK >= 1, bucketing logic that assumes the first valid value is 1, or visualizations whose x-axis starts at zero. Those assumptions can silently exclude future-period submissions rather than fail loudly after October 14.

The first task is therefore an inventory, not a rewrite. Search transformation code, semantic models, saved queries, BI calculations and alert rules for WEEK and for the two affected table names. For every dependency, record whether the business question is about active-period behavior, all submissions for a fiscal period, or the evolution of a future forecast. That intent determines whether negative values belong in the result.

Test row count and grain as well as value range

Gong notes that multiple future-period submissions can now be represented separately. That means the migration is not only about allowing a minus sign. A downstream model that assumed one row per user, team or period may see additional records and can multiply joins if the grain was never declared explicitly. Before the change, document the intended key for every derived table that consumes submission history.

Build a test fixture with at least one active-period submission, more than one future-period submission for the same fiscal period, a missing submission and a boundary case near period start. Run the existing transformation and compare row count, uniqueness, totals and dashboard filters. A successful parse is not enough; the test should prove that the analytical grain still matches the decision the report supports.

Separate historical comparability from current correctness

When a source system begins exposing a state that was previously absent, historical charts can appear to change even if older records are untouched. A chart of submission timing may now include pre-period activity for new fiscal periods while old periods lack equivalent history. RevOps should label that coverage boundary rather than interpreting the difference as a behavioral shift without evidence.

For executive reporting, decide whether the metric definition changes prospectively on October 14 or whether a backfill exists that makes earlier periods comparable. If Gong does not provide equivalent historical rows, retain the distinction in metric notes and model metadata. Reprocessing old dashboards with a new semantic assumption does not manufacture evidence that the old source never recorded.

Make the release reversible

A safe migration keeps the old query logic and the revised logic available long enough to compare them. Add a temporary validation view that exposes raw WEEK, derived period timing and the record key side by side. Run both versions over the same recent periods, inspect the exact rows that differ, then switch consumers only after the expected differences are understood.

If a dashboard or forecast review is business-critical, name the owner who can revert the semantic model or filter after the release. The rollback should restore a known reporting behavior without deleting the new source rows. That lets the team investigate an interpretation problem while preserving the raw evidence Gong now supplies.

What DailyRevOps would check before October 14

Search every warehouse and BI dependency for the affected tables and WEEK field, then classify each use as active-period only, future-period aware or ambiguous. Add negative-value and multi-row fixtures to the model tests. Verify primary keys and joins. Review dashboards for hard-coded axis ranges, filters, conditional formatting and calculations that divide or bucket by week number.

Finally, write a one-paragraph data contract that says what WEEK means before, during and after the forecast period, which rows each business metric includes, and when the revised definition becomes authoritative. The value of the migration is not merely avoiding a broken query. It is preventing a small upstream semantic change from becoming an unexplained change in a forecast decision.