In planning, forecasting, and enterprise reporting, report structures are rarely static. Category names evolve, product hierarchies get relabeled, and organizational units are frequently renamed (for example, updating a cost center name).
In dynamic reporting tools, visual annotations, custom formatting, cell comments, writeback, and manual data inputs (such as budget overrides or forecast updates) are attached to specific row dimensions. By using Dimension ID Mapping, you can link custom visual elements and planning inputs to a constant, non-changing identifier (such as a unique Product ID or Cost Center Code) rather than a volatile descriptive label (such as Product Name).
When row labels in your underlying data model change (e.g., renaming a product), standard reporting visuals lose track of which row the custom notes, cell highlights, or data inputs belong to.
The following screenshot shows a note added, approval status set to completed, and custom formatting applied to the Ergonomic Executive Backpack row.
If you change the row label, in this example, change Ergonomic Executive Backpack to Standard Laptop Backpack, you lose the custom formatting, data inputs, and annotations tied to the label.
Planning and forecasting workflows also require writing data back to database tables or data warehouses. If writeback relies on descriptive labels that change over time, it creates orphan records or breaks audit trails.
By default, notes, comments, and formatting are tied directly to volatile dimension labels. Configure dimension ID mapping to link these inputs to persistent, unique identifiers (like a Product ID or Cost Center Code).
Setup dimension ID mapping before making changes such as creating data input fields, adding notes, or applying formatting to the planning sheet.
Mapping a dimension label to a unique Column ID prevents unnecessary row creation during writeback. When enabled, updating a dimension label updates the existing record rather than creating a new row in the writeback table. Without dimension ID mapping, label changes are treated as new entries, generating duplicate rows.
Notice how the RegionID and SalesRepID are written back to the destination table although they are not added to the planning sheet.
The following screenshot shows the writeback table data if the label columns are not excluded in writeback settings (Step 2).
