Changelog
Follow up on the latest improvements and updates.
RSS
new
All Plans
UI & Reporting
Dashboards: View-Based Widget Preset Filters
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.
new
All Plans
Mobile
Mobile: Power Search
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.
improved
All Plans
Automations & Integrations
Webhook Trigger: Optional and Required Fields
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.
new
All Plans
Automations & Integrations
Automations: Conditional Logic
Automations pick up a new Conditional Logic action that lets a single automation take different paths depending on record data. Solution Managers build conditions with the standard condition builder, then place the actions that should run when conditions are met and the actions that should run when they aren't. Route ITSM tickets to the on-call team when priority is high, auto-approve purchase requests under a threshold and route larger ones for review, or send only backordered line items down a follow-up path inside a Repeating Action loop.
Key Highlights
- Single Automation, Multiple Paths: Replace the pattern of duplicated automations (one per scenario) with a single automation that branches based on record data. Fewer automations to maintain, fewer places where logic can drift out of sync.
- Standard Condition Builder: Conditions use the same control that already drives filters and automation conditions — AND/OR combinations, grouped condition sets, all field types supported. No new syntax to learn.
- Any Action Type in Either Branch: Both the "conditions met" and "conditions not met" branches accept any of SmartSuite's automation action types — updates, notifications, record creation, integrations, and more.
- Per-Item Evaluation Inside Repeating Actions: Placed inside a Repeating Action loop, Conditional Logic evaluates once per item in the loop, so a single run can send some items down one path and the rest down the other.
- Nesting Support: Pairs with this same release's Advanced Logic Nesting to allow branches inside branches, loops inside branches, branches inside loops, and loops inside loops (two levels deep).
- Full Traceability: Run History shows the evaluated values on the Conditional Logic step, so teams can debug why a given item took the path it did.
How It Works
- Open an automation and add an action. Choose Conditional Logic from the action picker.
- Build the conditions in the standard condition builder — combine multiple conditions with AND/OR, group as needed, reference any of the triggering record's fields.
- Add the actions that should run when the conditions are met to the first branch, and the actions that should run when they aren't to the second branch. Any action type is allowed in either branch.
- To evaluate per item inside a loop, place the Conditional Logic action inside a Repeating Action — each item in the loop is evaluated independently.
- Save and enable the automation. Open Run History to see which branch ran for each execution.
Solution Managers and Workspace Administrators can build and edit these automations. Available on all plans.
new
Enterprise
Signature
Automations & Integrations
Automations: Slack Actionable Notifications
Automations can now send Slack messages with actionable buttons that update a SmartSuite record when clicked. Solution Managers pick a target record, compose the message, and choose a Status, Single Select, Multiple Select, or Yes/No field on the record as the button source — Slack recipients get up to three buttons and clicking one sets that field to the corresponding value in SmartSuite. Approval flows for contract sign-off, expense review, PTO requests, or GRC control attestations run entirely inside Slack while the audit trail lands on the SmartSuite record.
Key Highlights
- New Automation Action: "Send an actionable notification" under Slack in the automation action picker. Available once the Slack integration is enabled at the workspace level.
- Up to Three Action Buttons: Buttons are sourced from a Status, Single Select, Multiple Select, or Yes/No field on the target record. Clicking a button sets that field to the corresponding value.
- Channel or DM: Send the actionable notification to a Slack Channel (the SmartSuite bot must be added to the channel first) or to an Individual Slack user (resolved from a Members list, a Trigger field like Assigned To or Contact Email, or a dynamic Formula result).
- Permission-Aware: The Slack user who clicks a button is matched to a SmartSuite Member by email, and their record permissions are checked before the update runs. Unauthorized clicks return a "not enough permissions" response in Slack.
- Full Audit Trail: Successful updates land on the record's activity history with the Slack user's name and the automation name attached. Failed attempts are captured as comments on the record on behalf of SmartSuite Automation.
- One Execution per Notification: Each notification can be actioned once — after any button click, the notification is spent regardless of the outcome.
How It Works
- A Workspace Administrator enables the Slack integration from Workspace Settings → Security → Access. The setup authorizes SmartSuite's connection to the Slack organization and adds SmartSuite to the specific Slack workspaces that should have access.
- Solution Managers open an automation and add the "Send an actionable notification" action. They pick the target record (from the Trigger, a Single Find, or a Repeating Action's Current Item), choose Channel or Individual as the message type, and address the message.
- Compose the message title and content — rich text formatting, inline record field values, and an Open Record link are supported.
- Pick the field on the target record to drive the buttons (Status, Single Select, Multiple Select, or Yes/No). Add up to three buttons, mapping each to a field value and setting a label.
- Save and enable the automation. When it fires, the recipient sees the message with the buttons in Slack. A click updates the record in SmartSuite, and the activity history records who did what.
Requires the Slack integration enabled at the workspace level. Available on Enterprise and Signature plans.
new
All Plans
Automations & Integrations
Automations: Advanced Logic Nesting
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.
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.
new
All Plans
Files and Images Field: Attachments limit
The Files and Images field can now cap how many attachments a single field instance will accept. Solution admins turn on "Limit the number of allowed attachments" in field settings and set the maximum — the field then refuses uploads beyond that count. Contract tables enforcing exactly one signed PDF per record, product catalogs capping reference images at a fixed number, HR employee profiles allowing only one headshot, and any workflow where the attachment count is a first-class part of the data model get field-level enforcement.
Key Highlights
- New Field-Level Setting: "Limit the number of allowed attachments" appears in the Files and Images field's configuration modal. Off by default; existing fields keep their current unlimited behavior until an admin explicitly turns the limit on.
- Whole-Number Maximum: When enabled, a numeric input accepts a whole-number maximum (default 1). Decimals, zero, and values above the system maximum are silently ignored — the input reverts to the last valid value, keeping the setting model predictable.
- Enforcement at Upload Time: The constraint is enforced at the record edit surface — uploads beyond the configured count are refused, so the invariant holds when the value is entered rather than surfaced as a validation error after save.
- Backward Compatible: Existing Files and Images fields are unaffected unless a solution admin opts into the limit. No migration; no accidental data loss on records already exceeding a newly-configured limit.
- Same Governance Model as Other Fields: The setting sits with the rest of the Files and Images field configuration, exposed to Solution Managers and Workspace Admins per the standard field-configuration permission model.
How It Works
- Open the field settings on a Files and Images field (or create a new one).
- Toggle on "Limit the number of allowed attachments." A numeric input appears with a default value of 1.
- Enter the maximum attachment count (whole numbers only). Save the field.
- On the record edit surface, the field now refuses uploads beyond the configured count. Users see the constraint at the point of upload rather than after save.
Available on all plans; existing Files and Images fields keep their prior unlimited behavior until an admin explicitly opts into the limit.
new
All Plans
UI & Reporting
Linked Records: Record Selector Dropdown Mode
The Record Selector on Linked Records now opens as an inline dropdown by default instead of a full modal. Picking from a short list of existing records to link takes one click and no modal round-trip; the modal experience is still available for longer lists and advanced browsing. Service desks assigning a ticket to one of a small set of Change Requests, sales teams linking a deal to an Account from a short recent-account list, GRC compliance teams connecting a control test to a filtered short-list, and PMO leads connecting a task to a Sprint from a handful of active options all get quicker linking on the common case.
Key Highlights
- Dropdown by Default: The Record Selector now opens as an inline dropdown when users click into a Linked Record cell, cutting the full-modal round-trip out of the common single-click pick.
- Same Records, Same Configuration: The dropdown surfaces the same records the modal would show — same Solution-Manager-configured static and dynamic filters, same sort order, same Fields configuration (from the Advanced Settings introduced in prior releases), same Grouping (from the Jul 27 Grouping for Record Selector release).
- Modal Still Available: When users need the richer browsing experience — grouped views, filter panels, advanced controls that don't fit inline — the modal is one click away as an expansion from the dropdown.
- Inline Search: Users can type in the dropdown to filter the visible records, the same way they would inside the modal.
- No Configuration Migration: Existing Linked Record fields inherit the dropdown default automatically; no Solution Manager action required, no data changes, no configuration migration.
How It Works
- Open a record and click into any Linked Record cell to open the Record Selector. The Selector opens inline as a dropdown by default.
- Scroll through the visible records or type to search within the list; click a record to link it. No modal opens.
- When the dropdown isn't enough (long list needing filter panels, grouped browsing, or other advanced controls), click the expand affordance to open the full modal instead — same records, same configuration, richer surface.
Third refinement in the Linked Records 2.0 arc, following the Sticky Add New button and Grouping for Record Selector from Jul 27.
new
All Plans
Data & Field Management
Assign and @-Mention Teams in Comments and Checklists
Comments and Checklist Items now support Team assignments and Team @-mentions, extending the Teams Field infrastructure from field-level assignments into the two most conversational surfaces in SmartSuite. Assign a Team to a comment or checklist item instead of picking a specific member, or @-mention a Team inline; every Team member gets an in-app notification and (if a Team Email is configured at the workspace level) one email goes to that address instead of individual member emails. ITSM service desks routing tickets to on-call teams, GRC compliance teams assigning control-review checklists to review committees, PMO leads @-mentioning cross-functional teams in project discussions, and HR teams distributing onboarding checklists across a Team all get first-class Team routing.
Key Highlights
- Team Assignments on Comments and Checklists: Assign a Team to a comment or checklist item exactly the way you'd assign a member. Every Team member receives an in-app notification; email routing follows the workspace-level Team Email setting (single address if configured, individual members if not).
- Team @-Mentions on Comments and Checklists: Type @followed by a Team name in a comment or checklist item; the mention resolves to the whole Team with matching notifications. Notification wording distinguishes mentions from assignments ("mentioned {Team} team" vs "assigned {Team} team").
- Same Governance as the Teams Field: Only active, non-deleted Teams that currently have Contributor or Assignee access to the record appear in the picker or @-mention list. Deleted or Inactive Teams are filtered out; the "Everyone" pseudo-team is never available.
- Team Email Deduplication: If a Team has a Team Email configured at the workspace level, that single address gets the email — no individual member emails. Multi-team memberships deduplicate cleanly so users aren't double-emailed when a Team Email address is in play.
- Full Audit Trail: Team assignments and mentions log in the record's activity history the same way Member assignments and mentions do — preserving traceability for compliance, incident post-mortems, and audit reviews.
How It Works
- Open a record and go to the Comments panel (or open a Checklist field and target a checklist item).
- Type @followed by a Team name in the comment field. The picker shows Teams that are active, non-deleted, and currently have Contributor or Assignee access to the record.
- Optionally check "Assign Comment" (or the equivalent on a checklist item) if you want the mention to be an assignment as well as a mention.
- Send the comment / save the checklist item. In-app notifications go to every Team member; email routes to the Team Email if configured, else to individual members (capped at 50 recipients).
- Resolve/reopen a Team-assigned comment the same way you'd resolve a member-assigned one. Team members see the resolution notification.
With Team assignments and @-mentions on comments and checklists, SmartSuite closes the gap between record-level Team routing (already available on the Teams Field) and conversation-level Team routing — the right responder can now be "whoever on this Team picks it up first" across every collaboration surface.
Load More
→