Best Of

I would like to be able to modify the "suggested" list with my own suggestions!

Yes please, I do not like that it defaults to the suggested list instead of my workspaces.

I really appreciate the current cross‑sheet reference functionality in Smartsheet but creating additional references for the same source sheet—especially after one already exists—can feel repetitive. It would be incredibly helpful if, once a cross‑sheet reference is created, that reference became accessible to all other sheets within the same workspace.

Ideally, users could select from a list of existing references or call them directly within formulas, without needing to recreate them each time.

This would be especially valuable when:

• You need to duplicate a sheet because you’ve hit row or column limits
• Multiple sheets must be re‑synced to the same data source
• You’re working with several criteria-specific sheets that all reference the same underlying data

This enhancement would streamline setup, reduce manual duplication, and help maintain consistency across large, multi‑sheet solutions.

Conditional Column Visibility Within Sheets (Dynamic Columns Based on Filed Selection)

Forms in Smartsheet support conditional logic. However, the sheet interface itself does not currently support rules-based column behavior.

We are requesting the ability to define logic that dynamically controls column visibility based on values selected in another column.

Proposed Behavior:

Allow administrators to define rules such as:

• If Phase = “Validation” → display validation-related columns
• If Phase ≠ “Validation” → suppress validation-related columns
• If Status = “Blocked” → display resolution and dependency fields
• If Status ≠ “Blocked” → suppress those fields

This would enable the sheet grid to respond intelligently to workflow state.

Why This Is Important

Our sheets represent full lifecycle processes. A single sheet must contain all phases for governance, reporting, and blueprint provisioning, yet only a subset of fields is relevant at any given time.

Without rules-based column behavior:

• Sheets become excessively wide (30+ columns)

• Users scroll horizontally and overlook required inputs

• Data accuracy declines

• Training overhead increases

• Teams duplicate sheets to simplify execution

With rule-driven visibility:

• The sheet becomes workflow-aware and state-aware

• Users interact only with fields relevant to their current phase

• Data quality improves

• Blueprint-driven solutions scale more cleanly

• Administrative complexity decreases

This would elevate Smartsheet from a static tracking grid to an intelligent execution interface.

Additional Enterprise-Oriented Enhancements

1. Conditional Required Fields - Allow columns to become required only when defined conditions are met Example: “Block Reason” required only when Status = Blocked
2. Collapsible Column Groups - Allow logical column groupings (e.g., Intake, Execution, Validation, Closeout) to collapse/expand within the sheet
3. Blueprint-Level Logic Inheritance - Allow rule definitions to be set once within Control Center so provisioned sheets inherit the logic automatically

Business Impact

We are building a standardized operational framework intended for reuse across multiple departments. This feature would directly reduce configuration complexity while improving:

• Data integrity

• User adoption

• Training time

• Blueprint scalability

• Governance reporting quality

This capability would meaningfully enhance enterprise workflow design within Smartsheet.

This is such a great idea, and I think it’s really going to open up a lot more capability and customization. It’ll make it so much easier for users to get the resource‑management data that actually matters to them.

Summary of Issue

All team members work a standard 7.5‑hour day, but only a portion of that day is allocated for project work (e.g., 25%, 50%, etc.). In Resource Management, however, the system currently interprets allocations as a percentage of the full 7.5 hours, instead of the project‑eligible portion of a person’s day.

This causes Resource Management to misrepresent a resource’s available project hours and incorrectly calculate actual hours when allocations are imported from project timelines.

Current Behavior

• All staff have a standard full-time schedule of 7.5 hours/day.
• A team member may only be available for projects at, for example, 10% utilization, meaning they should have 0.75 project hours/day.
• When timeline allocations (expressed as % of a standard workday) are imported, Resource Management calculates actual hours against the full 7.5 hours rather than the utilization-adjusted project hours.
• Differentiate between allocation % and Utilization %
  • Currently Resource Management is treating this as one in the same.

Example

• Team member attends a 1-hour meeting → shown as 13% on a timeline (1 ÷ 7.5).
• The resource’s project availability is 10% of 7.5 = 0.75 project hours/day.
• Resource Management incorrectly applies 13% to 0.75 instead of recognizing the actual 1 hour worked.
• Result: RM shows 0.10 hours instead of 1.0 hour.

Impact

• Project actuals are under-reported.
• Capacity and utilization metrics become inaccurate.
• Tracking of true time spent on project work is distorted.
• PMs cannot reliably forecast or assess project workload across the portfolio.

Requested Enhancement

Goal:

Enable Resource Management to calculate available project hours based on utilization percentage, while still recognizing that allocation percentages from project timelines are based on a standard 7.5‑hour workday.

We request the following enhancements:

1. Availability Calculation Option Based on Project Utilization

Introduce a system setting that allows Resource Management to compute daily project availability such as:

Available Project Hours = Standard Workday Hours × Project Utilization %

Instead of treating the full 7.5 hours as available for project calculations.

2. Correct Interpretation of Imported Allocation Percentages

Allocation percentages imported from project timelines should be interpreted as:

% of a standard 7.5‑hour workday—not as a percentage of adjusted, utilization-based availability.

3. Updated Actual Hours Calculation Logic

When allocation % is imported, Resource Management should compute:

Actual Hours = Allocation % × Standard Workday Hours (7.5)
—not
Actual Hours = Allocation % × Utilization-adjusted available hours

This ensures 1 hour of real work is logged as 1 hour, regardless of utilization percentage.

4. Optional Override at Resource or Project Level

To support flexibility, allow organizations to specify whether a resources project availability should be based on:

• Standard full-time hours,
• Utilization-adjusted project hours, or
• A custom per-resource project capacity.

Expected Outcome

• Actual project hours logged match real time spent.
• Utilization reporting accurately reflects % of project capacity used.
• Timeline imports no longer produce distorted numbers.
• PMs get reliable forecasting, capacity, and workload reporting.

As per the attached, I would like to a single row, with color coding, to reflect the various phases of a project in Timeline view and Gantt view. The importance of this view is to give Sr Leadership and Stakeholders a simple, visual overview of projects. We currently track in an xls document but this is static and not linked to our projects in Smartsheet. I have met with Smartsheet Pro and was told this is currently not possible so I am requesting an enhancement.