Differences between SFU Groups and SFU Maillist

OVERVIEW

This article describes the feature differences between SFU Groups and SFU Maillist.

 

CHANGED FEATURES

The following features will not be available in SFU Groups (when compared to SFU Maillist):

  SFU Groups
Owner role Owner role has merged with manager role. This is to ensure that group ownership isn't tied to an individual and become stale.
Deliver Mail to Members by Default

Always on. Users can no longer turn off email delivery from Exchange Distribution Groups they belong in.

Note: Managers won't receive emails if they are not a member of the group.

Delivery Suspended No longer available. Users can no longer turn off email delivery from Exchange Distribution Groups they belong in.
Welcome Message No longer available.
Change Log Only available to IT admins.
Delivery History No longer available.
Sender Restriction

(Allow List)

Stays available, but emails sent to a sender restricted Distribution Groups have additional security requirements.

With Exchange Distribution Groups, this will require any sender to authenticate to Exchange. This means that users will need to be signed into an SFU's Approved Email Application in order to send emails to an Exchange Distribution Group with Restricted Senders.

If the sender has not authenticated to Exchange, they will receive a bounce-back message saying their email has not been delivered. In most cases, this applies to those you use IMAP/POP (except for Thunderbird with OAuth2), any unapproved email applications, and any unapproved email integrations with M365.

Migration Impact Note:

After migrating these maillists to Exchange Distribution Groups, this setting will be turned off by default. If you wish to continue having restricted senders on your Distribution Group, you will need to re-enable this setting.

Only course/plan groups will have their Restricted Sender settings migrated.

Maillist Nesting

Since the permissions model is different in SFU Groups, all owners of groups that contain a nested group will require Group Reader Permissions to that nested group.

Migration Impact Note:

Since the permissions model is different in SFU Groups, if you are an owner of a maillist with a nested maillist, you will now require Reader or Manager Permissions to that nested maillist when maillists are migrated over as Exchange Distribution Groups.

Example:    

dept-managers-all

  • unit-a-managers
    (nested maillist)
  • unit-b-managers
    (nested maillist)
  • jane_doe@sfu.ca
    (owner)
  • john_doe@sfu.ca
    (member)

In this example, Jane Doe is an owner of dept-managers-all.

Jane Doe now requires Reader or Manager permissions for unit-a-managers and unit-b-managers in SFU Groups.

My nested maillist are within my department

If you also happen to be the owner of that nested maillist, you don't need to take additional action. If the nested maillist is not owned or managed by you, you should get manager role for that maillist prior to migration for a seamless transition to SFU Groups.

Be sure to check on the Active Maillist Migration List to see if you have any maillists that have "nested non-owned lists". Contact the maillist owners of those "nested non-owned lists" for manager role to those nested maillists.

My nested maillist are cross-department

If the nested maillist is owned by someone from another department, you should get manager role for that maillist prior to migration for a seamless transition to SFU Groups.

Be sure to check on the Active Maillist Migration List to see if you have any maillists that have "nested non-owned lists". Contact the maillist owners of those "nested non-owned lists" for manager role to those nested maillists.

Nested maillist from another department where they haven't been migrated yet:

  • Your nested maillist will be automatically removed from the membership list.
  • Once removed from the membership list, you will need to wait until the other department has also migrated. If you followed the steps above prior to migration, you should have manager role to the remove nested maillist. Simply re-add the nested maillist on SFU Groups.

Nested maillist from another department where they already migrated:

  • If you followed the steps above prior to migration, you should have the correct privileges to the nested maillist on SFU Groups. You don't need to take additional action.

 

Self-subscribe or unsubscribe No longer available. Use SimpleList if you require this feature.
Delays If you are making changes to Exchange Distribution Groups or security groups linked to a Microsoft service (e.g., Teams, SharePoint), you will need to wait an additional 30 minutes for your changes to fully sync to Microsoft servers.

 

ADDED FEATURES

The following features will be new to SFU Groups (on Grouper):

  SFU Groups
Composite Groups (dynamically generated groups) Only available to IT admins
Creating Permissions and Attributes Only available to IT admins
Inherited Permissions and Attributes Only available to IT admins
Role Permissions and Privileges Automation Only available to IT admins
Audit Logs Only available to IT admins
Group Types and Folders Only available to IT admins
Attestation and Group Validation Only available to IT admins

* IT admins refers to those who have access to the full Grouper interface, which may include members of the local IT administrators and other technical group managers.

 

NEED ADDITIONAL SUPPORT?

For questions about Group Management or SFU Groups:

For additional assistance:

Print Article

Related Articles (1)

SFU Maillist to SFU Groups migration tracking.

Related Services / Offerings (2)

Tools that provides the ability to send email messages to multiple email addresses using a list or a group.
Group Management simplifies access management by letting you use the same group or role across many services at SFU.
Loading...