Linked Record fields pick up Dynamic Filters — viewer-facing filter controls that let end users slice the linked-record list without editing the field configuration. Configured on the new Filters tab of the Advanced Settings modal, Dynamic Filters render as a filter picker at the top of the Linked Record display surface so viewers can filter by any field on the target table at view time.

Key Highlights

• New Filters Tab: Under the Linked Record field's new Advanced Settings modal (also shipping this release), a Filters tab lets Solution Managers pick None, Static, or Dynamic.

• Viewer-Facing Filter Controls: Dynamic Filters render as a filter picker on the Linked Record's display surface (Record Page, Record Details Widget). End users choose values to narrow the visible list without touching the field configuration.

• Same Filter Widget Behavior: Dynamic Filters reuse the same functionality already implemented for the Filter Widget's dynamic filters — no new logic, no new UX. Solution Managers who already know Filter widgets already know Dynamic Filters.

• Configure Which Fields Users Can Filter By: Solution Managers configure which fields on the target table are exposed as filter dimensions. Common picks: Status, Assigned To, Due Date, Priority, any Single Select or Yes/No.

• Per-Viewer, Per-Session: A user's Dynamic Filter selections don't persist to other viewers of the same record. Each user gets their own live view.

• Preserves Underlying Links: Dynamic Filters change what displays, not what's linked. Every linked record remains linked at the data layer.

How It Works

• Open a Linked Record field's settings and click Advanced Settings.

• Switch to the Filters tab and choose Dynamic.

• Configure the filter dimensions viewers can use — which fields are exposed and in what order.

• Save. On the Record Page and Record Details Widget, users see a filter control at the top of the Linked Record field and can filter the visible records by the exposed dimensions.

• Filter selections are per-viewer and per-session — they don't change what's linked, and they don't affect what other users see.

Third of the three Linked Record enhancements shipping this release, alongside Advanced Settings (the container modal) and Static Filters (author-driven preset filter sets). Static and Dynamic Filters share the same Filters tab — pick one flavor per field. Available on all plans.

Learn more

Watch product video

Linked Record fields pick up Static Filters — preset filter conditions on the field itself that let Solution Managers control which linked records display, without touching how records are actually linked. Configured on the new Filters tab of the Advanced Settings modal, Static Filters use the same condition builder that already drives Filter widgets and view controls. A default "All {record name}" filter is added automatically so users can always see the full set of linked records; additional filter sets can be added for common slices.

Key Highlights

• New Filters Tab: Under the Linked Record field's new Advanced Settings modal (also shipping this release), a Filters tab lets Solution Managers pick None, Static, or Dynamic.

• Static Filter Sets: Configure any number of named filter sets on a Linked Record field. Each filter set uses the same condition builder that already drives Filter widgets and view controls — no new syntax.

• Automatic "All" System Filter: When Static Filters is enabled, a system filter labeled "All {record name}" is added automatically. It shows every linked record, has a read-only label, and can't be removed — so users always have a way back to the full set. Solution Managers can reposition it in the list.

• Same Condition Builder: The Filter widget's condition builder is reused verbatim — no code duplication, no new UX to learn.

• Viewer Sees a Filter Picker: Configured Static Filters appear as a picker at the top of the Linked Record's display surface. Users switch between filters to see the corresponding slice of linked records.

• Preserves Underlying Links: Static Filters change what displays, not what's linked. Every linked record is preserved on the record; the filter is a display-time overlay.

How It Works

• Open a Linked Record field's settings and click Advanced Settings.

• Switch to the Filters tab and choose Static. The system adds an "All {record name}" filter automatically (read-only, non-removable).

• Add additional named filter sets using the standard condition builder — filter by field values, sort, group, whatever narrows the display to a useful slice.

• Save. On the Record Page and other Linked Record display surfaces, users see a filter picker at the top of the field and can switch between the configured filter sets.

• All linked records remain linked at the data layer; Static Filters only change what's displayed.

Second of the three Linked Record enhancements shipping this release, alongside Advanced Settings (the container modal) and Dynamic Filters (viewer-driven filter controls). Available on all plans.

Learn more

Watch product video

The Linked Record field settings pick up a new Advanced Settings modal that consolidates the display-configuration controls (Fields to Display, Group, Sort) and adds new capabilities on their own tabs. The modal opens with a live Preview on the left rendered from the last 50 records of the target table, and organizes settings across General (display format + Fields / Group / Sort), Filters (new — Static and Dynamic filters, ships alongside this release), and Actions (later phase) tabs. Simplifies the main Linked Record field settings screen while making the advanced surface much easier to configure.

Key Highlights

• New Advanced Settings Button: A single Advanced Settings button on the Linked Record field configuration opens the new modal. Fields, Group, and Sort controls move from the main settings screen into the modal so the main configuration surface stays clean.

• General Tab: Display format, Fields to Display, Group, and Sort in one place. Same functionality as before, better-organized surface.

• Filters Tab (new this release): Configure Static Filters (fixed conditions the viewer can't change) and Dynamic Filters (viewer-facing filter controls) on the Linked Record field. Ships alongside Linked Records: Static Filters and Linked Records: Dynamic Filters this same release.

• Actions Tab (placeholder): Reserved for a later phase.

• Live Preview: The left panel renders a live preview of the configured Linked Record using the most recent 50 records from the target table, so Solution Managers can see the effect of every configuration change without leaving the modal.

• Same Underlying Behavior: This is a UI reorganization plus a new Filters capability, not a change to how Linked Records themselves work. Existing configured Linked Record fields inherit the new modal automatically.

How It Works

• Open a Linked Record field's settings. In place of the previously-exposed Fields, Group, and Sort controls, an Advanced Settings button now appears.

• Click Advanced Settings to open the modal. The General tab loads by default with the display format, Fields, Group, and Sort controls.

• Switch to the Filters tab to configure Static or Dynamic filters on the field (or leave as None).

• Watch the live Preview on the left refresh as you change settings, sampled from the last 50 records of the target table.

• Save. Configuration applies to the Linked Record field everywhere it's referenced.

Second of three Linked Records enhancements shipping this release, following the Jul 27 Sticky Add New + Grouping and Aug 17 Dropdown Mode releases. Available on all plans.

Learn more

Watch product video

The Checklist field type is now supported on Form Views. Solution Managers can drag a Checklist field onto a form and configure it with all the standard form field settings plus Checklist-specific settings for entry creation, default-entry editing, Due Dates, and Assignments.

Key Highlights

• Full Checklist Support on Forms: Every Checklist field type property that works inside the main app now works on a Form View, so form respondents can complete a Checklist as part of a form submission.

• Standard Form Field Settings: Required, Help Text, Default Value, Show only when conditions are met, and Display help text as tooltip all work the same way they do for every other field type on a form.

• Checklist-Specific Settings: Users can create new entries (default on), Users can modify and delete default entries (default off), Enable Due Dates (default on), Enable Assignments (default on) — each configurable per form.

• Permission-Aware Assignee Picker: When Assignments are enabled, the Assignee picker only shows members that have access to the target table. Same behavior as the Checklist field inside the main app.

• Notification Routing: When a checklist item is assigned through a form submission, a notification is generated for the assignee. Internal forms attribute the assignment to the submitter; public (Shared) forms attribute the assignment to the SmartSuite Form system user.

• Team Assignments Supported: The existing checklist_team_assignment workspace flag is respected on forms too — when the flag is on, Checklist assignments to Teams work on forms the same way they work inside the main app.

How It Works

• Open a Form View in edit mode and drag the Checklist field from the Left Side panel onto the form.

• Configure standard form field settings (Required, Help Text, Default Value, display logic) in the field's edit mode.

• Configure Checklist-specific behavior: entry creation, default-entry editing, Due Dates, Assignments.

• Publish or share the form. Respondents can add checklist items (if enabled), edit default entries (if enabled), set due dates on items (if enabled), and assign items to members (if enabled).

• When items are assigned, notifications route to the assignee. Internal form submissions attribute the assignment to the submitter; public form submissions attribute the assignment to SmartSuite Form.

Available on all plans.

Learn more

Watch product video

Everything anchors to a Projects table — stage, owner, dates, budget, RAG status — and everything else links back to it: Tasks for the day-to-day execution work, Deliverables that track key outputs and automatically calculate their own % complete from linked tasks, Milestones for timeline and Gantt visibility, and Change Requests kept entirely separate from regular tasks. Rounding it out are Status Reports for keeping leadership updated, and Staffing, which tracks who's allocated where and how workload's distributed across projects.

Why it's built this way

That Change Requests / Tasks split isn't incidental — it's there specifically to stop scope creep from sneaking in disguised as "just one more task." A change has to go through its own capture-review-approve path instead of quietly landing on someone's to-do list. Same logic applies to Staffing living on its own: resource allocation and workload balance become visible in their own right, instead of being buried inside individual task assignments where nobody notices until someone's overloaded.

Built around who's actually looking at it

This template doesn't assume everyone needs the same view. Project Managers get full oversight and approve changes. Team Leads coordinate assignments and keep an eye on workload balance. Contributors just see their own tasks and can flag blockers. Stakeholders get milestone and status summaries without wading through task-level detail they don't need. And Executives or PMO leads can roll individual projects up into full programs or portfolios to compare performance at a glance.

The part that saves real time

Deliverables pulling their % complete automatically from linked Tasks means nobody's manually updating a progress number — it just reflects reality. Layer in the optional AI Assist extensions and a good chunk of routine project work disappears on its own: generating an initial project plan straight from a brief description, auto-summarizing weekly status reports from task and deliverable activity, classifying incoming change requests by risk/scope/budget impact and suggesting a recommended action, and flagging at-risk projects by spotting overdue tasks and repeated blockers before they become a real problem.

Making it your own

• Add a Risk Register table if you're running anything governance-heavy that needs formal issue tracking

• Turn on Portfolio Rollups once you're juggling more than a few projects, so leadership gets cross-project KPIs without opening each one individually

• Connect integrations to your existing dev tools, time tracking, or financial systems so project data stays current automatically instead of manual re-entry

Show us yours: Adapted this template for your own process? Tell us what you changed and why

The Webhook Received automation trigger picks up per-field Required controls and a distinct Rejected run-history status. All fields in the webhook structure are non-required by default; toggle Required on the fields that truly matter, and requests that arrive without one of those fields return HTTP 400 to the caller (naming the offending field) plus a Rejected run in history — separate from Failed and Error. Non-required fields no longer break the whole run when missing. Incoming webhook payloads are now captured in Run History as an expandable tree (parsed and raw) for every run, including rejected ones.

Key Highlights

• Fields Are Optional by Default: Every field in the configured webhook structure is now non-required by default. A missing or empty field on a non-required field no longer rejects the incoming request or fails the automation.

• Per-Field Required Toggle: Each field in the structure gets a Required toggle. Toggle it on for the fields that truly matter — a payment webhook's amount, a signup webhook's email — and only those fields gate the request.

• Rejected Run-History Status: Requests that fail the Required-field gateway land in Run History with a distinct Rejected status, visually separated from Failed / Error. No action steps execute for a rejected request.

• HTTP 400 Response to Callers: Rejected requests return HTTP 400 with the offending field name(s) in the response body —

  {"error": "Missing or empty required field(s): status"}

  — so the calling system can react cleanly.

• Payload Capture in Run History: The incoming webhook payload is now recorded on every run — successful, rejected, and failed. Rendered as a collapsed-by-default expandable key:value tree, with a View Raw toggle for the raw request body.

• Deterministic Handling of Empty vs. Absent: Present-and-empty and null both write empty to the target field. Absent-from-payload also writes empty (per the latest team decision). Present-with-value uses the value.

• Extra Fields Ignored: Payload fields not in the configured structure are accepted and ignored — no error, no surface. Delete unneeded fields from the generated structure without consequence.

• Migration: All existing webhook automations move to the new behavior automatically.

How It Works

• Open a Webhook Received trigger in an automation. Every field in the configured structure now shows a Required toggle in field settings, off by default.

• Toggle Required on for the fields that truly need to be present for the automation to make sense. Leave the rest off.

• When a webhook arrives, the trigger checks Required fields first. If any Required field is absent, null, or empty, the trigger returns HTTP 400 with the offending field(s) named, records the run as Rejected, and does not execute action steps.

• If all Required fields pass, action steps run. Each step maps values from the payload independently — empty and null both write empty, absent also writes empty, values are used as-is.

• Open Run History to see the incoming payload on any run (successful, rejected, or failed) as an expandable tree, with View Raw for the raw body.

Available on all plans. All existing webhook automations migrate to the new behavior — no reconfiguration required.

Learn More

Watch Product Video

Power Search comes to SmartSuite Mobile. Tapping the Search icon on iOS or Android now opens a Power Search modal that reproduces the desktop experience — workspace-wide record search across every Solution and Table, with the same filter set that the desktop Power Search provides. Field service techs looking up a work order without remembering which Solution it's in, ITSM agents pulling up an incident from a customer name typed at the pump, and PMO leads finding a task assigned to a specific member across every project all get the same "find anything from anywhere" experience mobile that they already had at their desk.

Key Highlights

• Workspace-Wide Mobile Search: Tapping the Search icon on the mobile app opens a Power Search modal that searches record content across every Solution and every Table in the workspace — no more homepage-scoped or Table-scoped search on mobile.

• Desktop Filter Parity: The mobile Power Search modal offers the same filter set that the desktop Power Search provides — narrow the result set by Solution, by Table, by field values, or by any other filter dimension supported today on web.

• Native Mobile UI: The Power Search modal is a native mobile interface, not a mobile-browser fallback — matching the native-mobile experience the app already provides for Grid, Calendar, Card View, Chart View, Internal Forms, and Shared Forms.

• No Configuration Required: Every mobile user picks up the new behavior automatically once they update the SmartSuite Mobile app.

• Continues the Mobile-Parity Arc: Ships alongside a multi-week mobile-parity push — Jul 20 Calendar and Card View widgets, Aug 3 Chart Widget, Aug 10 Internal and Shared Forms, and now Aug 31 Power Search.

How It Works

• Update the SmartSuite Mobile app to the latest version on iOS or Android.

• From the Home screen or from inside any Table, tap the Search icon.

• The Power Search modal opens. Type a search term to search record content across every Solution and Table in your workspace.

• Apply filters to narrow the result set — the same filters available in desktop Power Search work here.

• Tap a result to open the record.

Available on all plans. No configuration required.

Learn More

View-Based dashboard widgets pick up a third filter layer: Preset Filters on the widget itself, configured in a new Filters tab. Solution Managers choose Static (fixed conditions the viewer can't change) or Dynamic (viewer-facing filter controls on the widget so dashboard consumers can slice the data themselves). Preset Filters combine with the existing Filter Widget and the widget's own Filter Control using AND logic. Shareable dashboards expose Dynamic Filter controls to recipients with the full record set intact.

Key Highlights

• New Filters Tab: A dedicated Filters tab on the widget configuration modal, with a Preset Filters section that lets Solution Managers pick None, Dynamic, or Static.

• Static Preset Filters: Fixed conditions the dashboard viewer can't change. The author writes the filter once and every viewer sees the same slice.

• Dynamic Preset Filters: Viewer-facing filter controls that render on the widget so dashboard consumers can slice the data themselves without editing the dashboard configuration — Status, Assigned To, Linked Record, date range, and any other filterable field type.

• Same Condition Builder: Preset Filters use the same condition builder as the Filter Widget and every other filter surface in SmartSuite — no new syntax to learn.

• Three Filter Layers, All ANDed: Filter Widget (dashboard-wide), Filter View Control (widget-level, editor-owned), and Preset Filters (widget-level, author- or viewer-owned) all combine as AND-joined condition groups. Any narrowing in one layer stacks with narrowing in the others.

• Preset Type Switching Preserves Work: Only one Preset Filter type can be selected at a time, but switching between Static and Dynamic preserves any conditions already configured so authors can flip between the two without rebuilding.

• Shareable with Full Record Set: Sharing a dashboard exposes Dynamic Preset Filter controls to recipients with no pre-selection applied and the full underlying record set intact — a viewer's live filter selection never truncates the data other viewers see.

• Reference-Field Support: Dynamic Preset Filters based on Linked Record, Assigned To, or Lookup fields surface the reference records recipients need in the picker after sharing.

How It Works

• Open a View-Based widget's configuration modal on a dashboard.

• Go to the new Filters tab. In the Preset Filters section, choose Dynamic or Static (or leave as None to skip this filter layer).

• Configure the filter conditions using the same condition builder that drives the Filter Widget and every other filter surface in SmartSuite.

• Save. If the type is Static, every viewer of the dashboard sees the same filtered slice. If the type is Dynamic, a viewer-facing filter control renders on the widget for consumers to slice with.

• Combine with the Filter Widget and the widget's Filter View Control — all three layers work together as AND-joined condition groups.

Available on all plans.

Learn More

Watch Product Video

The Button field's click events on a record's activity history now record the user who clicked and the action that ran (Create a Record, Open a Form, Open URL, or Run an Automation). Button-driven workflows that dispatch actions from a record — service-desk agents opening a ticket-creation form, GRC reviewers launching an automation to snapshot evidence, PMO leads clicking through to a linked record — now have per-user attribution in the audit trail instead of an anonymous "button was clicked" entry.

Key Highlights

• User Attribution on Every Click: Activity history now identifies the user who clicked the button by name — no more anonymous entries in the audit trail.

• Action Type on Every Click: The log entry also records which action ran — Create a Record, Open a Form, Open URL, or Run an Automation — so auditors can distinguish a link-out from an automation trigger without cross-referencing the button configuration.

• Click Events Remain Separate: Button click events continue to be logged as their own events, never grouped with other field changes on the same record — preserving the pattern that made these entries usable for audit and incident review.

• Covers Every Button Action Type: All four Button action types (Create a Record, Open a Form, Open URL, Run an Automation) capture the same enriched context.

• Covers Every View That Supports Clicks: Grid, Card, Kanban, and the record edit surface all route their Button clicks into the same enriched activity log. Extended and Table formats for Linked Records that display Button fields do too.

• No Configuration, No Backfill: Existing Button fields inherit the enriched logging automatically. No configuration migration; historical activity history entries are not backfilled.

How It Works

• Users click a Button field on a record (in Grid, Card, Kanban, the record edit modal, or an Extended/Table Linked Record display). The configured action runs the way it always has.

• Open the record's activity history. The click event now shows the user's name and the action that ran — for example, "Peter Novosel clicked Submit for Review button. Action: Run an Automation."

• Auditors, incident reviewers, and compliance teams can trace per-user attribution directly on the record's own activity history without a separate log to reconcile.

Available on all plans. No configuration required; existing Button fields inherit the enriched logging automatically.

Learn More

Watch Product Video

Automations' Advanced Logic building blocks — Conditional Logic (new this release) and Repeating Actions (Looping) — can now be nested inside each other, up to two levels deep. That unlocks multi-level workflows: a branch inside a branch, a loop inside a branch, a branch inside a loop, and a loop inside a loop. Process a set of records, loop over each one, and within each loop branch on a per-record condition — all inside a single automation.

Key Highlights

• Four Nesting Combinations: A Conditional Logic branch inside another Conditional Logic branch (chained conditions), a Repeating Action loop inside a Conditional Logic branch (loop only when conditions are met), a Conditional Logic branch inside a Repeating Action loop (evaluate conditions per item in the loop), and a Repeating Action loop inside another Repeating Action loop (iterate through a nested set).

• Two Levels of Nesting: Advanced Logic actions are available at the top level and at one nested level. At the second-level nested action, the picker offers every other action type but not further Advanced Logic.

• All Other Action Types Unaffected: Updates, notifications, integrations, record creation, and every other automation action type remain available at every level of nesting.

• Same Editor Experience: The condition builder inside a nested branch works the same way as at the top level. The Current Item and Trigger data are available at every nesting level.

• Full Traceability: Run History expands each nested step so teams can trace which branch ran and which items in a loop went where.

How It Works

• Open an automation and add a Conditional Logic action (new this release) or a Repeating Action (Looping).

• Inside a branch or a loop, add another Advanced Logic action to create a second level of nesting.

• Inside that second-level action, add non-Advanced-Logic actions (updates, notifications, integrations, and more). Further Advanced Logic nesting is not offered at this level.

• Save the automation and open Run History to trace how each execution resolved through the nested levels.

Ships alongside this release's Conditional Logic launch — the two features together are what "Advanced Logic" means in SmartSuite Automations. Available on all plans.

Learn More

Watch Product Video