A high-performance glove features multi-layered shock-dispersing foam, ergonomic thumb locks, and reinforced wrist support. From traditional lace-up competition gloves to convenient hook-and-loop training gloves, selecting the right size (8oz to 16oz) and padding density ensures long-term comfort and durability during grueling gym sessions.

At MaxMyer, Australia’s premier destination for authentic combat gear located at 6 Tech Wy, Cranbourne, VIC, fighters and trainers can access commercial-grade gloves from world-renowned combat brands including Cleto Reyes, Sting, Rival, Fairtex, Venum, Green Hill, and RDX. Engineered with genuine cowhide leather and high-density foam cores, these gloves provide ultimate protection round after round.

Ready to upgrade your hand gear with equipment built for maximum fight performance? Explore authentic sparring and training gloves directly in the official MaxMyer Boxing Gloves Collection to secure your ideal pair today.

Scripts that sync data or call external services have needed a home where administrators can see what exists, when it runs, and whether it worked. Script Engine is that home: a new page in Workspace Administration to create, schedule, and monitor the JavaScript scripts in your workspace.

Key Highlights

• One Script Directory: Every script in the workspace in one list, showing status, schedule, and recent activity, with columns you can show, hide, or reset.

• Health At A Glance: Counts for active scripts, scheduled scripts, and failed runs in the last 24 hours sit above the list, and each one filters it in a click.

• Built-In Code Editor: Write or paste JavaScript, then set Memory and Timeout limits for each script.

• Secrets By Reference: Choose which workspace secrets a script can use, so credentials never live in code and rotate in one place on the Secrets page.

• Flexible Scheduling: Run scripts Hourly, Daily, or Weekly, or on a custom rate or cron expression.

• Run History: Every run is recorded with its execution mode and the script version that ran, with filtering, sorting, and per-run details.

• Evidence Collection On A Schedule: A daily script can pull control evidence from an external system into your compliance records, and its run history shows each collection ran.

How It Works

• Open Workspace Administration and select Script Engine, directly above Secrets.

• Create a script and enter a name and a Script ID of 3 to 63 lowercase letters, numbers, and hyphens, unique within the workspace.

• Write the JavaScript, set Memory and Timeout, open Choose secrets to tag the secrets it needs, and save.

• Saved scripts are validated, and the status badge shows Active, Inactive, or the validation failure, with the reason on hover.

• Duplicate a script to try a change safely; the copy needs its own Script ID before it saves.

• Export the script list to CSV, Excel, or Google Sheets, or a single script to JSON with secret references and never secret values.

Script Engine gives every script in the workspace a clear record: what it does, when it runs, which secrets it uses, and how each run went.

Learn more

Watch product video

Ever create record after record and type the exact same value into the same field every single time — same starting status, same assignee, same linked account?

The tip: Field-level Default Values auto-fill a field the moment a new record is created, so you’re not manually re-entering the same thing over and over.

Where to find it: Open the field’s settings (three-dot menu → Modify Field Settings) → go to the Defaults tab → set the value you want every new record to start with.

A few specific examples worth knowing:

• Status fields — set a default like “Backlog” so every new record starts at the right stage of your workflow automatically

• Assigned To fields — choose “Record Creator” as the default, so whoever creates the record is automatically assigned to it

• Linked Record fields — pre-populate a specific linked record (like always linking new tasks to a particular project) so people don’t have to search and select it manually every time

One thing worth knowing: defaults only apply to new records created after you set them — existing records keep whatever value they already had.

Bonus — Forms work a bit differently: on a Form, you can set a default value specific to that form, which overrides the field’s own default just for that form. So the same underlying field can default to one thing on your internal form and something else entirely on a public-facing one.

Quick rule of thumb: If you’re typing the same value into a field on nearly every record you create, stop — set a default instead.

Got a default-value setup that’s saved you real time? Tell us below.

Deleting a team used to be final, which made the safe move leaving unused teams inactive rather than removing them. Deleted teams now go to the Recycle Bin, where an Administrator can restore one.

Key Highlights

• Teams Are Recoverable: A deleted team now moves to the Recycle Bin instead of disappearing, so an accidental delete is no longer permanent.

• Administrator Restore: Members with the Administrator role restore a deleted team from the Recycle Bin, alongside the other items collected there.

• Membership Comes Back: Restoring a team returns it with its members, so you are not rebuilding the roster by hand.

• Cleaner Team Lists: With deletion reversible, you can remove teams you no longer use instead of parking them as inactive to stay safe.

• Access Reviews: Teams grant permissions, so recovering one that was removed in error keeps an access review from turning into a rebuild.

How It Works

• Delete a team as before, from Workspace Administration, Manage Teams, by opening the team and choosing Delete Team.

• The team moves to the Recycle Bin rather than being removed outright.

• Open the Recycle Bin, find the team among the deleted items, and choose to restore it.

• The restored team reappears in Manage Teams and can be used again wherever teams grant access.

• Setting a team to inactive is still there when you want to keep it in place but stop it granting permissions.

Removing a team is now a reversible action, so tidying up your workspace no longer carries the risk it used to.

Learn more

Watch product video

Dynamic filters on a dashboard could only ask one question: is the value this. Filtering a widget to everything except a status, or everyone other than one person, meant building a second widget to get there. Dynamic filters now carry an operator you choose, so a single control can include or exclude.

Key Highlights

• Is And Is Not: Every dynamic filter now supports both operators, so one control can narrow to a value or exclude it.

• Operator Per Filter: Each filter in the widget carries its own operator, so one can include while another excludes in the same set.

• A Chosen Default: Pick the condition that is pre-selected when someone expands the filter, instead of always starting from Is.

• Changed On The Dashboard: Viewers switch the operator from the filter's footer without opening widget settings or editing the dashboard.

• Open Work At A Glance: Exclusion makes the common service view simple, filtering a ticket dashboard to Status is not Closed without a second widget.

How It Works

• Open the widget's Filters tab, add a dynamic filter on a field, and set its Default Condition to the operator you want pre-selected.

• The Default Condition setting sits alongside Selections, Default Value and Sort Values in the filter's settings dropdown.

• On the rendered widget, the filter footer shows the field label next to the operator as a dropdown, for example Status Is.

• Viewers change the operator there, choose values, then apply by clicking Apply, clicking outside the control, or pressing Enter.

• Conditions from the filter widget combine with a connected widget's own filters using AND, so the widget's existing filters are preserved.

Dynamic filters can now exclude as easily as they include, with the default condition yours to set and the operator the viewer's to change.

Learn more

Watch product video

The core structure: Three linked tables do the work — Orders, Invoices, and Customers. Orders capture what was sold (order date, items, shipping fees), Customers holds the contact/billing details, and Invoices pulls from both to assemble a complete, accurate bill — including a Total Amount field that’s automatically calculated from the linked order, not manually entered.

Why this matters: Because the Total Amount is pulled from linked Orders rather than typed in, there’s no risk of an invoice quietly drifting out of sync with what was actually ordered. If the order changes, the invoice reflects it — you’re not maintaining the same number in two places.

The mechanism that does the heavy lifting: Document Designer. Instead of manually formatting a PDF each time, a template combines static labels (like “Invoice,” field titles for invoice number/date/customer) with dynamic data pulled directly from the linked Orders and Customers records — order date, itemized list, shipping fees, billing address — all populated automatically when you generate the document.

Where this fits in a bigger picture: This template is part of SmartSuite’s Logistics solution area, alongside Inventory Tracking — so if you’re also managing stock levels or supplier relationships, Orders and Invoicing is built to connect with that wider supply-chain structure rather than standing alone.

How to adapt it:

• Add fulfillment checklist fields to Orders if you need to track shipping/packing status before invoicing

• Customize the Document Designer template’s static labels and layout to match your own branding

• Link a Payments or Accounts Receivable table if you need to track partial payments against an invoice

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

I’m building a master calendar that shows scheduled jobs from several departments, each living in its own solution. I need the events to be highlighted/coloured based on a specific field (in my case field team), so I can’t just overlay several calendars using the multiple-calendar option in the calendar view settings. That option doesn’t give me the colour-coding I need across sources.

What I’ve tried and why it falls short:

1. Automation creates a duplicate record in a central calendar table, with a lookup field pulling in the date and the field the highlighting depends on. The source date field is a date range, and a lookup of a date range doesn’t show up on the calendar view.

2. Copy the source date range into a real date range field on the central table when the record is created. This displays correctly, but the date is now stored in two places. If someone edits the range in only one record, the two get out of sync, and for scheduling jobs that’s too risky.

3. Formula to convert a looked-up date range into a true date range field. I couldn’t find one.

My questions:

• Is there a way to make a lookup of a date range display on a calendar view that I’m missing?

• Is there a formula or other method to turn a looked-up date range into a real date range field, so the source stays the single point of truth?

• Is there a better pattern for pulling records from multiple solutions into one calendar with conditional colouring?

• If none of this is possible today, I’d like to suggest it as a feature request: either support for lookup date ranges in calendar views, or colour-coding across multiple overlaid calendars.

Thanks in advance.

API keys and tokens sitting inside script code are a liability every auditor asks about. Secrets now has a page of its own under Workspace Administration, where you store sensitive values once, reference them by name, and see exactly who revealed each one and when.

Key Highlights

• Dedicated Page: Secrets has moved out of the Script Engine and onto its own page in the left sidebar, directly below Script Engine.

• Values Out Of Code: Scripts and integrations reference a secret by name, so API keys, tokens and connection strings never appear in the script itself.

• Reveal Is Recorded: Every reveal saves the member's name and the time, giving Administrators an access trail for sensitive credentials.

• Usage Before Changes: The Used in column shows every script and integration depending on a secret, so you can check impact before rotating or deleting it.

• One Rotation, Everywhere: Updating a secret's value takes effect in everything that references it, so rotating a credential is a single edit.

How It Works

• Open Workspace Administration and select Secrets to see the list, search it by name, and sort by secret name.

• Create a secret with a name and a value. The value is encrypted on save, and only its last four characters are ever shown in the list.

• Revealing a value takes two steps: a warning that the action is recorded, then the full value in a read-only field with a Copy button.

• Editing lets you rename a secret without breaking references, or type a new value to overwrite the existing one. Values are write-only and never displayed.

• Deleting a secret that is in use lists the affected scripts and integrations, turns them off, then removes the secret. The action cannot be undone.

Credentials now live in one governed place, with a record of every reveal and a clear view of what depends on them. Available now on Enterprise and Signature plans.

Learn more

Watch product video