Changelog

Follow up on the latest improvements and updates.

RSS

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.
Whats New page - Forms - The New Listing Page
Solutions now have a dedicated Forms page in the Solution menu that shows every form in the solution as a tile, grouped by its target table. Service desks running multiple intake forms, GRC teams maintaining attestation forms across control areas, and HR programs juggling onboarding, leave, and exit forms can all manage their forms from a single operational hub instead of hunting through individual tables.
Key Highlights
  • Tile-Based Layout Grouped by Table: Every form in the solution renders as a tile showing title, target table, shared status, and a preview of the first page. Tiles are grouped alphabetically by table, with a sidebar of tables for quick navigation.
  • Shared and Draft Badges: A Shared icon flags forms exposed internally or externally. A Draft badge calls out forms that have never been shared, signaling they are not yet usable as a Form View or via a Button action.
  • Three-Dots Menu Per Tile: Hover any form to surface Copy Internal URL, Copy Shared Link, Edit, Duplicate, and Delete, exactly the actions builders reach for most often.
  • Search and Empty State: A top-right search field filters by form title while preserving the table grouping, with a clear No Results message. Solutions with no forms see a Welcome to SmartSuite Forms onboarding state with one-click new-form creation.
  • New Form Dialog: Create Form opens a focused dialog with required Title (validated for uniqueness with a live preview) and required Table (dropdown of every table in the solution); Create Form drops the user straight into the Edit Form screen.
How It Works
  • Open any solution where you have Solution Manager permissions and click the new Forms item in the Solution menu.
  • Browse forms grouped by their target table, or jump to a specific table by clicking its name in the sidebar.
  • Hover a tile and use the three-dots menu to Copy Internal URL, Copy Shared Link, Edit the form, Duplicate it (appends 'Copy' to the title), or Delete it.
  • Use the search input in the top right to filter by form title; results stay grouped by table.
  • Click New Form to open the Add New Form dialog, enter a unique Title and pick a Table, and click Create Form to save and jump into the Edit Form screen.
Pairs naturally with the rest of the Forms 2.0 work this year, including Multi-Page Forms, Progress Bar, Enhanced Submission Page, and the Submittable Form View.

new

All Plans

Internal Form View

AppCue -  Forms - The New Listing Page
The Form View has been redefined. It is now a view type linked to an underlying source form, rendered in ready-to-fill state for any table member with view access. Service desks placing an intake form in every team's view panel, HR teams attaching onboarding forms to people tables, and GRC programs putting attestation forms next to control records all get a one-click submission surface inside the work they already do.
Key Highlights
  • Submittable, Not Just Editable: The Form View now displays the linked form in a ready-to-fill state for every table member with view access, not just Solution Managers.
  • Linked to a Source Form: Pick any internally-shared form from any solution you manage as the view's source. The view stays in sync with edits to that source form.
  • Solution Switcher and Search: The Select Form modal shows forms across every solution you manage, grouped by table, searchable, with inline new-form creation.
  • Manager Controls: Solution Managers can rename, swap to a different source form, edit the underlying form, or delete the view from the view properties.
  • Migration Handled: Existing legacy Form Views are removed from the views panel; Solution Managers should use the new Forms page to edit forms, and create a new Form View only when they want the form exposed for internal submission.
How It Works
  • Add a Form View to a table; the Select Form modal appears with internally-shared forms grouped by table across every solution you manage.
  • Pick a form (or create a new one inline) and the view links to that source. The view name inherits from the source form by default.
  • Any member of the table with view access opens the Form View and submits the form, subject to record-create permissions on the target table.
  • A Solution Manager can change the linked form, edit the form's fields via the designer, rename the view, or delete it; only Solution Managers see these controls.
  • If the source form is deleted in the Forms page, every Form View that referenced it is removed automatically.
Use this when a form needs to be available inside the team's existing workspace rather than as a public link, especially for high-volume internal submissions like ticket intake, attestation, or onboarding requests.
Load More