Filter and trigger on who owns the record by group, not just by individual user. Two new operators — Belongs to Group and Does not belong to Group — are now available on every user-based field, everywhere conditions are written: workflows, reports, and list-view filters. The Last Modified By field has also been opened up so the full set of equality and group operators is available on it.

Every record in the CRM has at least one user-based field — Assigned To. Opportunity records additionally have Sales Rep and Closing Agent. Every record everywhere has Last Modified By. Until now, conditions on those fields were limited to a small set of operators:

That worked for “is the record owned by Jane Doe?” but not for “is the record owned by anyone on the West Coast Admissions team?”. Building the second kind of rule required listing every team member by name, and keeping the rule in sync as team members joined and left.

CRM-1730 closes that gap by adding two new operators to every user-based field’s condition picker, throughout the CRM:

It also broadens Last Modified By: in addition to Is Empty / Is Not Empty / Has Changed, the field now accepts Is, Is Not, Belongs to Group, and Does not belong to Group, the same as any other user-based field.

These operators are available consistently in all three places where conditions are written:

The same Group dropdown drives all three surfaces, so a Group you can pick in a workflow is the same Group you can pick in a Report or a List Filter.

The operators inherit the existing permissions of the surface they’re used in:

Picking a Group from the dropdown requires read access to that Group’s definition — which every CRM user already has, since Groups are part of the public sharing model.

Alongside the existing entries, you now see:

Pick one of those operators and a Group selector appears in the value column. The selector lists every Group defined in Settings → Roles & Sharing → Groups. Pick exactly one Group; save the condition.

Same two operators, same Group selector. Save the filter; share it with your team if it belongs to a role-wide view.

When the CRM evaluates Belongs to Group for a record:

Does not belong to Group is the strict negation of the above — including for records where the user-based field is empty (which counts as not belonging to any group).

Membership is dynamic. When a user is added to or removed from a Group, every condition that uses Belongs to Group picks up the change immediately on the next evaluation — no need to re-save the workflow / report / list filter.

The operator takes one Group at a time. To express “Belongs to Group A or Group B”, add two condition rows joined by OR — one for each Group. To express “Belongs to Group A and Group B” (a less common but valid case), add two rows joined by AND.

This matters most for Last Modified By on brand-new records, where the field has just been set, and for any Assigned To fields that are not mandatory.

The Last Modified By field is now treated as a full user-based field for condition purposes. Operators now available:

The same operator list is now identical across all four user-based fields you can routinely target — Assigned To, Sales Rep, Closing Agent, Last Modified By — so administrators don’t have to remember field-by-field exceptions.

A note on Has Changed. Has Changed is meaningful only inside workflow conditions (it compares the record’s before vs after state on save). It is intentionally not offered in report filters or list-view filters, where there is no “before save” state to compare against.

When a Lead’s Assigned To changes to anyone on the Admissions Team, the welcome email fires automatically. Adding a new admissions rep to the Group later requires no workflow edit — the next assignment to that rep also triggers the workflow.

If a confidential Contact is modified by anyone outside the Customer Service group, the security team gets pinged.

The report includes every open Opportunity whose Sales Rep belongs to the West Coast Sales group, even when team membership changes between runs.

Share with the team. Every member sees the same evolving list of records owned by anyone in their Group, without each user maintaining a personal copy.

Useful for change-tracking audits: surface every record whose most recent change came from a non-admin user.

Detects when an Opportunity escalates from a junior counsellor (the previous owner) to a senior counsellor (the new owner’s group), and notifies the previous owner that the hand-off has happened.

If you currently maintain a workflow / report / filter with a stack of “Assigned To Is user A” OR “Assigned To Is user B” OR … rows:

From now on, adding or removing a user from the Group updates every rule automatically. You no longer have to revisit the rule for team changes.

The Groups page lists every Group, but does not currently surface “where is this Group used?”. To audit dependencies on a Group:

Before deleting a Group, scan each surface to make sure no critical rule depends on it. Deleting a Group used by a rule renders that rule’s condition unsatisfiable (it can match nothing) but does not delete the rule itself.

The new operators play with the standard AND / OR / NOT logic at every surface:

If a problem is not in this table, capture the surface (Workflow / Report / List), the condition row, and the Group name, and contact CRM support.

Q. Are Groups and Roles the same thing? No. Roles drive the user hierarchy (who reports to whom, who sees whose records). Groups are explicit named collections of users, often used for sharing. CRM-1730 is about Groups, not Roles directly. To filter by a Role, define a Group whose membership rule includes that Role.

Q. Can I match a user belonging to any of multiple Groups? Yes — add one condition row per Group and join them with OR.

Q. Does Belongs to Group honour role-based sub-groups inside the chosen Group? Yes. The expansion follows the same logic the rest of the CRM uses for sharing, including role-based and nested sub-groups.

Q. Will a workflow re-run if I add a user to the Group after the workflow already ran for that record? No. Group membership changes do not retroactively re-trigger past workflow runs. They affect every future condition evaluation.

Q. Can I use Belongs to Group in a report’s grouping (not filter)? No. The new operators are filter operators. Reports continue to group by the user-based field’s value (the user’s name); they do not group by Group membership directly. To produce per-group counts, build a saved-search per Group, or use a calculated field upstream.

Q. What happens to existing rules with Has Changed on a user field? Nothing. Has Changed continues to work in workflow conditions as before.

Q. Are the operators consistent between Standard Filters and Advanced Filters in Reports? Yes. Both surfaces expose the same operator set on user-based fields.

Q. Does this work on custom user-type fields I’ve added through the Layout Editor (e.g. a custom Account Manager user field)? Yes. Any custom field of type User/Group List (UI type 53) inherits the same operator set globally.

Q. Does it work with the User/Group dual-field type? The chosen user-based field’s user value is tested for Group membership. If the field holds a Group value directly (a User/Group field set to a Group), the operator simply asks whether that Group is the same as the picked Group — equivalent to Is.

Q. Can the Group selector pick a sub-group only, instead of its parent Group? The selector lists every Group defined in Settings → Groups, including sub-groups, by their explicit name. Pick the most specific Group you want to test against.

Q. Does this affect API or webservice queries? The new operators are exposed in the standard query builder, so any saved filter or report that uses them returns the same data via API/webservice as it does in the UI.

Q. Can I lock down which users can pick certain Groups? No. The Group selector shows every Group the user can see. Restrict via the standard Group visibility settings if needed.

End of guide — CRM-1730.