Regroup 

University Group Email (hereafter, GEM) using Regroup had the following organization with regard to list type and membership: 

List -> Opt-outs -> Group 

University members opted out of certain types of lists.  Lists were filtered by group-type opt outs when groups were updated every night.  For Official groups, of course, there were no opt outs. 

Thinking in Emma 

In using Emma, there are major differences in the way the members (now contacts) are identified.  While Regroup is a mass communication service, where groups are a natural organizational choice, Emma is a marketing automation service, in which the relationship of the sender to each recipient is the focus.  We’ll first concentrate on the replacement mechanism for Regroup’s permanent lists/groups: 

1)  Identifying recipients in Emma is determined by field values rather than group membership. 

Recall that with Regroup, we expressed relationships in terms of lists as follows: 

All students:  Jim T, John M, Jane G…. 

All employees:  Mary T, Larry Y, Jim T…. 

Staff Council District 250:  Jen C, Jill H, Mary T…. 

With Emma, recipients are defined by values in contact fields rather than being organized into lists.  The recipients chosen in this way are referred to as a segment.  The following table illustrates how our Regroup-style example above can be expressed in terms of contact fields: 

Contact fields can be true/false or contain text, numbers and/or blanks, depending on the definition of each.  You can create a segment from Student?=True, and that query would equate to the All Students group.  Likewise, we can create a segment for Staff Council District 250, which would be all the staff members with the value ‘250’ in the Staff Council District field.   We can even create a segment of all members represented by Staff Council where the Staff Council District value is not blank.  And since information will be fed to Emma from campus organizations updating the contact fields on a regular basis, the segments used to send messages are automatically updated.  The contact fields/segment organization is very powerful and yet simple in its basis and has the potential for allowing sets of recipients which were never feasible within the architecture of Regroup. 

2)  Emma's primary division is by silos of responsibility which determine access privileges, not recipient groups.   

The University has always had different organizations who are traditionally charged with responsibility for select populations at the University, such as the Registrar for students, Human Resources for staff (and, to a degree, for faculty), the Provost for faculty members, the Graduate School for graduate students, Moody College of Communication for Communications students, faculty and staff, and so on.  And all of these organizations are overseen by the President and/or the Provost.  Some of these responsible organizations have responsible for large populations (like all the benefits-eligible members) and others potentially much smaller (maybe McDonald Observatory staff some day?): 

Our University-wide Emma account has been organized into multiple subaccounts.  These subaccounts allow different organizations to control permissions to contact the different populations at the University.  Neverthless, GEM stewards and the Service Desk can still assist with questions and even authorizations.  (It might help to think of the entire GEM account as a United Nations, while each subaccount is similar to a country.) 

3)  Subaccounts include only part of the UT population represented in UT’s Emma account. 

For example, the Registrar’s subaccount will not need to have most employees, at least not the ones who are not also students.  An author should always ascertain that the subaccount that s/he uses contains the correct contacts.   

4)  Subaccounts include only relevant contact fields (and, thus, segments). 

For example, the contact field for Staff Council District will not appear in the SVP Infrastructure subaccount.  The segments which are contained by a subaccount may not be obvious, as with Student Employees, which will be in the HR subaccount but not in the Registrar’s subaccount.  An author should also be sure to ask whether the intended audience for a message is available from the subaccount. 

5)  Subaccounts can be Official or not.    

As with all previous services, community members will be allowed to opt out of non-Official messages.  However, important official and operational messages will be sent to all community members without filtering. 

6)  Segments can exist in more than one subaccount.   

A particular segment (such as All Students or All Employees) may be in multiple subaccounts, reflecting the ability of several different groups to authorize messages for this population.  [We’ll do our best to keep the Getting Authorized documentation up to date to minimize any confusion.] 

7)  Opt-outs are per subaccount. 

With Emma, opt-outs are at the subaccount level.  There will no longer be an Informational/Promotional distinction.   At the outset, all opt-outs will be set to opted in, and university members opt out through links in message footers.  Emma allows university members the opportunity to more finely tune one’s own opt outs.  Opting out from all optional messages will require contacting the GEM stewards. 

8) Segments are dynamic while groups are static.   

We haven’t talked about groups in Emma yet:  They do in fact exist but they have a subsidiary role. 

All of the information about segments and contact fields pertain to dynamic contacts:  When a contact experiences the change of a field (such as retiring, moving to a different department, becoming a Staff Council member), that contact can be removed from and/or added to one or more segments. 

However, groups are based on a static list of contacts, very similar to the custom lists feature we used in Regroup.  Groups are just lists of people and are not filtered; in addition they do not participate in modification due to changes in contact fields, so that is why groups are static.  As with Regroup’s custom lists, these static groups should only be used for a short time and for no more than a few messages. 

9) A message belongs to and is posted from a single subaccount.   

When a message is sent, all of the segments and groups chosen must be from the same subaccount.  The advantage is that only a single person can always approve the message.  The disadvantage is if the subaccount structure is not set up in such a way that a single subaccount contains all the needed groups and segments, there will need to be multiple approvers, there will be no suppression of duplicates, and the GEM stewards may be needed to copy the message from one subaccount to another. 

Short recap of all the information above:  The most important consideration for a sender within Regroup was “Am I sending to the right group?”  While with Emma there is a two-fold decision for the author.  First, “Do I have the right owners?”  Then, “Am I choosing the right segment(s) and/or group(s)?” 

The above consistitute the major differences between Regroup and Emma in providing our Group Email service.  If you are still not sure what to do, there is a simple form to use and the GEM stewards should be available to answer any questions.  Once you have the access you need, both the GEM stewards and Emma have other documentation to help you create and determine the recipients for your message. 

Emma-speak! (with translation from the Regroupese) 

Audience – tab on burnt orange nav bar; people who you intend to send a specific message to.  Authors cannot see the Audience tab and so should get the segment name from the GEM stewards or Managers before scheduling a message. 

Author – of subaccount, can write and schedule messages (similar to Authorized Sender in Regroup) 

Campaign –  tab on burnt orange nav bar; where message is written and directed from.  The Campaign section is called that because Emma allows for complex series of messages and workflow, whereas we are using Emma (so far) for one-off messages.  Starting a new message can be done from button “Create a New Campaign.” 

Contact – person who group email messages are sent to (similar to Member in Regroup); contacts do not have access to Emma. 

Group – a list of contacts in a subaccount, always static in Emma (could also be effectively dynamic in Regroup). 

Manager – of subaccount, can remove former Authors and approve/reject messages (similar to Moderator/Limited Admin in Regroup) 

Opt-Out – ability of a contact to choose not to receive messages from a subaccount.  (For Regroup, opt-outs were recorded in UT Direct.) 

Response – analytics for mailings, scored and extremely detailed.  Responses to mailings are also available on dashboard (similar to View Report in Regroup). 

Segment – a subset of the total contacts in a subaccount determined by an expression using one or more contact fields (similar to Group in Regroup, albeit determined very differently). 

Subaccount – a portion of the University of Texas at Austin’s group email account with specific managers, segments, contact fields, authors, and contacts (no similar concept in Regroup) 

User – someone with access to and permissions for Emma – a steward, a manager, or an author (technically similar to Admin in Regroup and sometimes mistakenly called Authorized Sender in member listings).  But note that the “User” listings in Emma may include authors but not managers. 

Other differences to note between Regroup and Emma 

The most important points in discussions below have been bolded. 

For Contacts 

People who are not Users cannot enter Emma, even to request authorization.  A new User (Author or Manager) needs to be authorized for Emma by the GEM stewards.  Therefore, the GEM stewards recommend using the ServiceNow forms for requests and service of any sort.   (Requests to be expedited can still be sent to the groupemail-internal@utlists.utexas.edu mail list.)  Any requests the GEM stewards cannot handle are forwarded to the person or people who can take the required action. 

For Contacts and Users 

Contacts in Emma should be identified by IID (Institutional Identifier) <eid>@eid.utexas.edu rather than by the official email address in the directory.  Messages to the IID automatically forward to the official email address.  Great care should be taken to avoid adding duplicate addresses for people.  Managers and authors may also be added by Emma as contacts, and that is officially the entry token as well, so when cc:’ing people, please always use the <eid>@eid.utexas.edu (“IID”) address. 

Gettin’ Stuff Done (Authors and Managers) 

There is no longer an option to compose group email messages in Outlook or other email clients for Emma.  All emails must be posted from within the interface.   

In Regroup, we chose the recipient groups for the message generally first, as it was at the top of the message template.  After that we brought in a template and/or composed the message.  In Emma, it’s the reverse:  We first create the message from a template. Only after the message is ready do we choose the sender and recipients. 

In Regroup, we avoided scheduling of messages.  In Emma, scheduling messages is the only option for Authors; Managers can change the schedule date if it is past to allow the message go out.  The date and time will display in red letters if the message will not go out if approved right away. 

Managers do not take an additional approval action in sending a message.  Also, messages from Managers do not need to be scheduled.  Managers do have the scheduling option, and that will keep a message from going out right away. 

Managers will now have ability to do more within their subaccounts; but taking actions other than the ones discussed here may make it more difficult for the GEM stewards to guarantee consistency of experience within the service.  Please email groupemail-internal@utlists.utexas.edu if you wish to use features we have not identified in this training so that we are aware of your usage; we prefer to help with such requests. 

Regroup offered no resources for avoiding a certain group in sending.  However in Emma, you can not only add multiple segments and groups to add to the recipient list; you can specify one group or segment to be removed from the recipients. 

Quirky but useful tidbits for Authors and Managers 

UT Austin has an Emma HQ account rather than an Emma Plus account.  Please always refer to documentation for Emma HQ whenever available. 

Authors and managers will not automatically receive emails sent by them or within the subaccount.  You will receive notice of the message and summaries and links to a detailed success report in your inbox within 24 hours of posting.  If you prefer the message in your inbox as assurance to know that the message went out, you can always cc: yourself as well as other members of your team, but please always use your IID (<eid>@eid.utexas.edu; see above in “For Contacts and Users”) to do so. 

A person can have only one single Emma “User” role in the UT Austin account; this includes ALL subaccounts.  For example, this means if Jenna Smith is already a manager for the Staff Council subaccount, she cannot be added as an author to an HR Infrastructure subaccount.  Making an author a manager is likewise prohibited.  Of course, the GEM stewards and managers can act together to promote or demote an individual for *all* role designations throughout the UT Austin account.  Unlike Regroup, one can be in both in the contact list and either an author or manager for a particular subaccount.  (If you believe some person MUST hold both an author and a manager role in separate subaccounts, please contact the GEM stewards.) 

Email footers are already present in the templates that you will use as authors and managers, unlike Regroup.  You are encouraged not to edit them, so that contacts can have a consistent email experience with University Group Email.  (Also please note that removing or editing certain parts of the email footers can cause Emma to reject the message as not well-formed.)