Changelog

Follow up on the latest improvements and updates.

RSS

Whats New page -  Filter - Support for lookup field
Dynamic Filter Widgets on dashboards can now filter by Lookup fields. ITSM service desks filtering a Tickets widget by the linked Change Request's Priority, GRC dashboards filtering a Findings widget by the linked Control's Status, and PMO dashboards filtering a Tasks widget by the linked Sprint's Owner all get filter behavior that reaches through the relationship instead of only working with the direct record's own fields.
Key Highlights
  • New Filter Source: Lookup fields join Status, Single Select, Multiple Select, Yes/No, Assigned To, Linked Record, and Date-based fields as choices in the Dynamic Filter's field-to-filter-by dropdown.
  • Full Target-Type Support: Lookups that resolve to Status, Single Select, Multiple Select, Yes/No, Assigned To (single or multiple), Linked Record (single or multiple), or any Date-based field all render as filter options with the right control for their type.
  • Same Configuration Surface: Selections (choices shown), Default Value, Default Condition, and Sort Values controls work exactly the same as they do for direct-field filters. No new configuration model to learn.
  • Reach Through the Relationship: Filter dashboard widgets by attributes of related records (the linked Change Request's Priority, the linked Control's Status) even when those attributes aren't fields on the source table directly.
  • Connected Widget Behavior Unchanged: The Lookup filter combines with the underlying widget's own filters using AND, matching the existing Filter Widget behavior, the filter narrows visible records, it never grants access beyond the widget's own scope.
How It Works
  • Open a dashboard you manage and add a Filter Widget, or edit an existing one; keep the Filter Type at Dynamic on the Filters tab.
  • Click Add Filter to add a new dynamic filter; the field-to-filter-by dropdown now shows Lookup fields alongside the other supported types.
  • Pick a Lookup field. The Filter Settings modal opens; the controls (Selections, Default Value, Default Condition, Sort Values) render based on the field type the Lookup resolves to, matching the direct-field filter experience.
  • Save the Filter Widget. Viewers see a filter tile with the Lookup's field label, and applying the filter narrows the connected widgets by the value the Lookup returns.
  • Use this whenever the filter criterion your team cares about lives on a linked record, reach for a Lookup field on the source table, then filter on that Lookup in the widget.
Pair this with the Static Filters mode released in the June 22 cohort for dashboards where the filter combinations are stable enough to expose as tabs.
Whats New page -  Forms - Footer
Forms now support a configurable Footer on the Style tab, giving form builders visual control at the bottom of the form to match what the Layout and Appearance sections provided at the top. Service desk intake forms with contact info and SLA reminders, GRC attestation forms with compliance boilerplate, and customer-facing forms with company brand messaging all now have a proper footer surface without leaving the form designer.
Key Highlights
  • New Footer Section: A dedicated Footer section on the Style tab exposes a toggle (default off), a rich-text Content editor, a Background Color picker, and a SmartSuite Branding toggle.
  • Rich-Text Content: Compose the footer content in a rich-text editor from the left side panel; formatting options include the standard font styles, links, and text emphasis available in the rest of the form designer.
  • Background Color from the Standard Palette: Match the footer to your form's Appearance or your brand's palette, with a custom-color picker available for exact matches. Default is White.
  • Display SmartSuite Branding Toggle: The small 'Powered by SmartSuite' line stays visible by default (on for most form owners), but can be toggled off when a fully-white-labeled experience is required for a customer-facing form.
  • Applies to Publicly-Shared and Full-Page Variants: Matches the rest of the Style tab's behavior, internal forms opened as a side panel continue to use the Classic layout without a footer, so the new setting only kicks in where it makes visual sense.
How It Works
  • Open the Style tab on any form in the designer and find the new Footer section in the left side panel.
  • Toggle Footer on. Two controls appear: Footer Content (rich-text editor) and Background Color (palette plus custom picker).
  • Compose the footer copy in the Content editor; use formatting for links, emphasis, and structure as needed. Pick a Background Color that complements your form's Appearance treatment.
  • Use the Display SmartSuite Branding toggle to keep or hide the 'Powered by SmartSuite' line at the very bottom of the form.
  • Save the form. The Footer renders on publicly-shared and full-page variants; internal side-panel forms continue to display without a footer.
Pair this with Forms: Layout and Appearance (Jun 22 release) and the rest of the Forms 2.0 work shipping this year for a full end-to-end style pass on any customer-facing or publicly-shared form.
Whats New page - Activity History - Link to Automation Run
Every automation-driven change on a record now includes a direct link to the specific automation run that made it, embedded in the record's Activity History. Change managers investigating an unexpected update, GRC auditors tracing per-record data changes to their source, and anyone debugging an automation outcome can now hop straight from the affected record to the run that touched it, instead of scrolling through the automation's run history one-by-one.
Key Highlights
  • Embedded Run Links in Activity History: Every automation-driven change on a record now includes a clickable link on that record's Activity History entry, pointing directly to the run in the automation's own History that made the change.
  • Bulk-Trigger Friendly: When a bulk trigger updates dozens or hundreds of records in a single run, the record-side link jumps to the specific run/record combination, so investigating a single unexpected outcome doesn't require a needle-in-haystack hunt through the run list.
  • Preserves Full Run Context: Following the link opens the automation run's details view with the trigger, input data, every step's outcome, error messages, and downstream side effects visible for review.
  • Applies to Every Change Type: Field updates, linked-record modifications, status changes, comment creation, any record-modifying automation step gets the same traceability.
  • Standard Permissions Apply: The run link respects the same automation-viewer permissions on the containing solution; it doesn't grant visibility to anyone who couldn't reach the run through normal navigation.
How It Works
  • Open the affected record and switch to its Activity History.
  • Find the entry for the automation-driven change you want to investigate (each entry shows the automation name, the change made, and the timestamp).
  • Click the run link on that Activity History entry; you land on that specific run's details view inside the automation's own History.
  • Review the trigger record, input data, and every step's outcome to understand exactly what the automation did on this execution.
  • Use this to diagnose an unexpected outcome on one specific record without having to walk through every run of a bulk-triggered automation.
Use this whenever a record ends up in an unexpected state and you need to trace exactly which automation execution caused it.
Whats New page - Linked Record - Default Value
Linked Record fields now support default values on the field, on Create-a-Record button actions, and on forms. Pre-populate the most common relationship so new records start with the right connections in place; multi-link fields can carry multiple defaults. Service desks routing new tickets to a default queue, GRC programs attaching new findings to a default control area, and PMO templates pre-populating a linked Sprint all benefit.
Key Highlights
  • Default Values on Linked Record: Pick one or more existing records (by Title) as the pre-selected value for any Linked Record field. Multi-link fields support multiple defaults; single-link supports one.
  • Three Places of Application: Set defaults on the field itself, on a Create-a-Record button action, or per-form. Form-level defaults override field-level defaults inside their form, matching the pattern from other Default Values work this year.
  • Search-and-Pick UI: The default picker reuses the existing Filter control for selecting records, with lazy loading for long tables and a search filter that kicks in once the choice list exceeds five records.
  • Graceful Deletion Handling: If a record used as a default is later deleted from the linked table, the default-value control voids automatically and falls back to a no-default state instead of erroring out.
  • No Retroactive Changes: The default applies only to new records created after the default is configured; existing records with an empty or different Linked Record value stay as they were.
How It Works
  • Open a Linked Record field's settings on any table where you have edit access, and enable the Default Value toggle.
  • Pick one record (single-link) or multiple records (multi-link) from the picker; use the search input to filter long lists.
  • Save the field settings. Every new record created in that table will pre-populate the Linked Record field with the selected record(s).
  • On a Create-a-Record button action, configure the same default-value control in the button's settings; the button's default applies when a user clicks it to create a record.
  • On a form, use the field-in-form default control to override the field-level default for that specific form; the form's default value takes priority when a submitter opens the form.
Pair this with the rest of the Default Values rollout this year, including Yes/No default values from last week and the broader Default Values framework in the form designer.
Whats New page - AI Center - support for new models
The AI Center now supports the latest flagship models from Anthropic, OpenAI, and Google Gemini, organizes every model into four clear price tiers, and retires deprecated model IDs. Cost-optimizing existing automations and upgrading to flagship reasoning for complex work both get a lot easier.
Key Highlights
  • Latest Flagship Models: Claude Opus 4.8, GPT 5.5, and Gemini 3.1 Pro (2M-token context) are available for the most demanding reasoning, extraction, and analysis tasks across the full Anthropic, OpenAI, and Gemini catalogs.
  • Four-Tier Pricing Structure: Every model is classified as Budget (up to two dollars per MTok output), Standard (two to six dollars), Premium (six to twenty dollars), or Flagship (over twenty dollars), so picking the right model for a workflow no longer requires researching each provider's pricing page separately.
  • Retired Models Removed: Anthropic's Sonnet 4, Opus 4, Sonnet 3.7, Sonnet 3.5, Claude 3 Haiku, and Claude 3 Opus are no longer callable on the API and have been removed from the catalog. Gemini 2.0 Flash and Flash-Lite are also removed.
  • Tier Revisions on Kept Models: Several models have moved between tiers to match current provider pricing (Sonnet 4.5 up from Standard to Premium; GPT 5.1 and GPT 5 down from Flagship to Premium; GPT 5 Mini and GPT 4o Mini down to Budget). Existing configurations continue to work; the tier badge is what changed.
How It Works
  • Open the AI Center in Workspace Administration and browse the refreshed catalog; models are grouped by provider (Anthropic, OpenAI, Gemini) and labeled with tier badges.
  • Pick the right model for a workflow based on tier: Budget for tagging and lightweight extraction, Standard for everyday summaries and structured output, Premium for content generation and analysis, Flagship for the hardest multi-step reasoning.
  • Configure the model on any AI Field Agent, AI Assist prompt, or automation-driven AI action; existing configurations continue to work unless they reference a removed model ID (in which case update to the recommended replacement).
  • Use the tier badges to spot cost-optimization opportunities: high-volume automation runs using a Premium model for a task that a Standard or Budget model could handle just as well are the easiest wins.
Applies to every AI-powered surface in SmartSuite: AI Field Agents, AI Assist, and automation-triggered AI actions.
Whats New page - Form - default values for yes no
Yes/No fields can now have form-level default values, joining the growing list of field types that support form-specific defaults. Set the starting state (Yes, No, or empty) per-form, so risk acknowledgment toggles default to No, opt-in checkboxes default to Yes when appropriate, and any boolean question comes pre-set to fit the form's audience.
Key Highlights
  • Yes/No Defaults on Forms: Configure a default value (Yes, No, or empty) for any Yes/No field on a form. Until this release, Yes/No fields on forms loaded blank.
  • Per-Field Per-Form Configuration: The same Yes/No field on the underlying record can default to Yes on one form and No on another, with no change to the field's underlying definition.
  • Form Defaults Override Field Defaults: A default value set at the form level takes priority over the default defined in the underlying field's settings, so each form expresses its own intent.
  • URL Parameter Priority Preserved: For publicly-shared forms, pre-filled URL parameters continue to take priority over form-level defaults, so query-string overrides still work as before.
  • Joins a Growing Default Values List: Adds to the field types already supporting form-level defaults including text, numeric, select-based, Linked Record, Assigned To, and date fields.
How It Works
  • Open a form in the designer and click any Yes/No field to enter its edit mode.
  • Find the Default Value toggle and switch it on; pick Yes or No (or leave the field blank for no default).
  • The canvas updates in real time to show how the field will render to submitters with the chosen default selected.
  • Save the form. Submitters see the configured default as the pre-selected state when they open the form.
  • On publicly-shared forms, URL parameters still override the form-level default when present, so existing query-string workflows continue to work.
Pair this with the rest of the Default Values rollout this year, including Linked Record default values and the broader Default Values framework documented in the form designer.
Whats New page - Filter Widget - Static Filters
The Filter Widget on SmartSuite dashboards now supports Static Filter mode. Solution Managers pre-configure named filter sets, the widget renders them as tabs across the top, and connected dashboard widgets re-load their data when a viewer clicks a different tab. Service desks toggling between ticket cohorts, GRC dashboards switching between audit areas, and PMO sprint dashboards flipping between sprint stages all get a viewer-facing filter surface that is consistent across the team.
Key Highlights
  • Static Filter Mode: Configure named, pre-baked filter sets on a Filter Widget instead of exposing fields for viewers to fill in. Each filter set supports multiple conditions and condition groups, just like Filter on a table view.
  • Tab-Based Viewer Experience: Configured static filters render as tabs across the top of the widget. Only one tab is active at a time, and any connected widgets re-load their data against the active filter set.
  • Up to 20 Per Widget: Add, edit, delete, and reposition up to twenty static filters per Filter Widget during configuration, with full drag-and-drop ordering.
  • Combines with Widget-Level Filters: Static filter conditions combine with the underlying widget's own filters using AND, so the Filter Widget never grants access to records that the widget would not show on its own.
  • Mode Switching with Preserved Config: Switch a Filter Widget between Static and Dynamic modes during configuration without losing the other mode's settings. End users cannot toggle between modes on the canvas.
How It Works
  • Open a dashboard you manage and add a Filter Widget, or edit an existing one; set the Filter Type to Static on the Filters tab.
  • Click Add Filter to add a new static filter; give it a name and compose its conditions using the standard Filter control (multiple conditions, condition groups, all supported operators).
  • Repeat for up to twenty filter sets per widget; drag the tiles in the configuration UI to reorder how the tabs appear on the rendered widget.
  • Use Connected Widgets on the General tab to specify which widgets on the dashboard should react to the Filter Widget; only widgets pulling data from the same table on the same tab are selectable.
  • Save the widget. Viewers see the static filter tabs across the top of the widget; clicking a tab activates that filter set and refreshes the connected widgets.
Use this when the dashboard's filter combinations are stable and curated by a manager, and you want viewers to switch between them with a single click instead of building filters themselves.
Whats New page - Form - layout and appearance settings
The form designer's Style tab now exposes a Layout section with Classic, Banner, and Full options, plus a new Appearance section for background color and button styling. Service desk intake forms can wear corporate branding, GRC attestation forms can use full-bleed hero imagery, and HR onboarding forms can match team-specific color treatments without leaving the form designer.
Key Highlights
  • Three Layout Options: Classic (form on a colored background, default), Banner (configurable banner image above the form with brightness and reposition), Full (edge-to-edge banner imagery, no reposition).
  • Banner Image Controls: Standard Assets Library for image selection, 0 to 100 percent brightness slider (default 50 percent), and real-time canvas preview. Banner layout also supports image repositioning within the banner area.
  • Background Color Control: New Appearance setting controls the form's background color from the standard SmartSuite palette or a custom value. Defaults to the Solution color. Rendered only when Layout is not Full.
  • Button Color Control: Same palette plus custom picker controls the Submit and Next button color. Defaults to the Solution color for consistent solution-level brand inheritance.
  • Internal Form Defaults: Classic layout is always applied to internal forms opened as a side panel, so Banner and Full are reserved for publicly-shared and full-page variants where hero imagery makes sense.
How It Works
  • Open the Style tab on any form in the designer and find the new Layout section in the left side panel.
  • Pick Classic, Banner, or Full. The form canvas updates in real time to show the selected layout.
  • For Banner or Full, click the banner area to open the Assets Library modal; pick an image, adjust the brightness slider, and (Banner only) drag the image within the banner area to reposition.
  • Open the Appearance section to set Background Color (palette plus custom picker) and Button color; both default to your Solution color.
  • Save the form. The selected Layout and Appearance treatments apply to the publicly-shared and full-page variants; internal side-panel forms continue to use Classic.
Pair this with the rest of the Forms 2.0 work shipping this year, including Multi-Page Forms, Progress Bar, Enhanced Submission Page, and the New Forms Page.
Whats New page - Form - single multiple select display types
Single Select, Multiple Select, and Status fields can now render on forms as Radio Buttons or Checkboxes instead of the dropdown default, with a configurable 1, 2, or 3-column layout. Service desk forms exposing all priority options at once, GRC attestation forms showing every compliance answer side by side, and HR forms surfacing role choices without a dropdown click all benefit from a more scannable submission experience.
Key Highlights
  • New Display Format: Single Select and Status fields can render as Radio Buttons; Multiple Select fields can render as Checkboxes. Dropdown remains the default.
  • Column Layout Control: When the new format is selected, choose 1, 2 (default), or 3 columns. Choices flow left-to-right, top-to-bottom across the selected number of columns.
  • Per-Form Configuration: The display format is set per-field per-form, so the same Single Select field can be Dropdown on one form and Radio Buttons on another without changing the underlying field definition.
  • Unselectable Radio for Non-Required Fields: If a Single Select Radio Button group is not marked as required, clicking the currently-selected option unselects it, leaving the field unanswered. Matches the standard radio button affordance on web forms.
  • Status Field Supported: The new format applies to Status fields in addition to Single Select and Multiple Select, so workflow-stage selections (Open, In Progress, Resolved, etc.) can also render fully exposed on the form.
How It Works
  • Open a form in the designer and click any Single Select, Multiple Select, or Status field to enter its edit mode.
  • Find the Display Format toggle in the field's edit controls and switch from Dropdown to Radio Buttons (for Single Select / Status) or Checkboxes (for Multiple Select).
  • Pick a Number of Columns: 1 for stacked, 2 for a two-column layout (default), or 3 for a denser three-column layout.
  • The canvas updates in real time to show how submitters will see the field.
  • Save the form. Submitters see the new layout on the live form; the underlying field definition is unchanged, so the same field on another form can keep using Dropdown.
Pair this with the rest of the Forms 2.0 work shipping this year, especially the new Layout and Appearance options and the Enhanced Submission Page.

new

Enterprise

Signature

Access & Security

Dynamic Record Permissions

Whats New page - Dynamic Record Permissions
Dynamic Record Permissions is now generally available. Solution Managers can build table-level rules that restrict who can View, Edit, Create, or Delete records, with scope down to individual tabs and sections and conditions tied to field values. GRC programs locking completed policies, audit programs making engagements read-only on completion, and security teams walling off sensitive records all now have a control surface that matches how their governance actually works.
Key Highlights
  • Cohort-Based Targeting: Pick Everyone, Only Selected, or Everyone Except as the audience, with a mix of teams, individual members, and permission types as the picker options. One rule can target a Team plus a permission type plus a named user in a single audience.
  • Four Restriction Types, Scoped Three Ways: View, Edit, Create, and Delete restrictions, each scoped to the whole Record, to selected Tabs, or to selected Sections, with optional conditions tied to Status, Single Select, Multiple Select, or Yes/No fields.
  • Sentence-Builder Rule Authoring: Build rules in plain language ('Sales Team can't edit records when Status = Completed') instead of writing logic by hand. Each rule has a title, description, audience, and one or more restrictions.
  • Layered Conflict Resolution: Multiple rules for the same cohort apply the strictest rule (least privilege). When a person belongs to multiple cohorts with conflicting rules, the least strict rule wins (optimistic) so collaboration is preserved. Record-scope rules take priority over Tab, then Section.
  • View As, Validation, and Safe Deletion: Test any rule with View As as the selected user. Invalid rules (missing audience, deleted tab, broken condition) auto-mark themselves invalid and stop applying. Tabs and Sections that a rule depends on cannot be deleted without first cleaning up the rule.
How It Works
  • Open a table you manage and go to the new Permissions section in table settings; this is where Record Level Permission rules live alongside the existing table-level permissions.
  • Click Add Rule, give it a Title (unique within the table) and an optional Description, then specify Who this rule applies to (Everyone, Only Selected, Everyone Except) and pick teams, members, or permission types.
  • Add one or more restrictions per rule: pick the action (View, Edit, Create, Delete), pick the scope (Record, Tab, Section), and choose Always or When conditions are true. Use the sentence-builder control to compose the condition.
  • Save the rule and it becomes effective immediately. There is no draft/publish state. Use View As on any rule's audience to verify the experience the restricted user will see.
  • Edit, duplicate, or delete rules from the Rules Overview page; conflicting rules resolve automatically per the documented priority order.
A note on the upgrade path: customers who used Dynamic Record Permissions in the early access period get the GA experience with no migration work.
Load More