Account Eligibility and Provisioning

Sub-organizations Based on Services

User accounts are provisioned and managed via sub-organizations (sub-org) within the Google Apps for Education (GAE) domain based on Institutional Roles on the individual’s MCommunity record. Services available in the domain are available on the List of Services page. The sub-orgs are:

  • All Services
    • All Core and Additional Services, no ads
  • All Services - Core
    • All Core Services, no ads (no Additional Services since user does not agree to terms)
  • Restricted
    • Contacts, Groups, and Docs enabled, Additional services enabled, No Mail, No Calendar
  • Restricted - Core
    • Contacts, Groups, and Docs enabled, No Mail, No Calendar (no Additional Services since user does not agree to terms)
  • Alumni
    • All Core Services with ads
      • Currently, there are no ads. If Google provides the ability to serve ads at the sub-organization level, we’re required to provide them.

Role Priority

The target sub-org is based on a priority of affiliations to the University. If a user’s status matches the criteria for an affiliation, the user is added to the corresponding sub-org. Matching a higher priority affiliation ignores any attributes that occur in a lower priority affiliation (i.e. if a user has a student affiliation, that trumps a unit affiliation for a unit with restricted data).

The driver places a user in the sub-org that matches the criteria below.  If the user does not agree to the terms for the Additional Services at the time they initially log in, they must contact the Service Center to be moved to the Core-Only equivalent of the designated sub-org. For example, if someone meets the requirements for a priority 1 (All Services), but has opted for Core services, they are placed in the All Services - Core sub-org. Note that Core services are not called out in the table below as they are sub-sets of their corresponding sub-orgs.

Priority Sub-Org Name Affiliation Sub-org Services MCommunity Institutional Roles
1 All Services Student All Services, no ads
StudentAA
StudentDRBN

Regardless of restricted flag or Flint roles. This state trumps the restricted flag.
2 Restricted Restricted Data User*
- includes Sponsored Accounts from units with restricted data use



No Mail, No Calendar, Some Core, All Addtional Services
StudentFlint*
FacultyFlint*
RegularStaffFlint*
TemporaryStaffFlint*

* is the only role
Restricted flag set to TRUE when VPArea=Med Affairs, or Org in College of Pharmacy or Health Service, or dept in Health Mgt Research Ctr (450100). Driver will also look at override value which will state which sub-org to put in when override in effect.  
3 All Services Ann Arbor Employee (Faculty, Staff, Temps, Emeritus)
- includes regular sponsored accounts with services

Dearborn Employee
All Services, no ads
FacultyAA
RegularStaffAA
TemporaryStaffAA
Retiree
FacultyDBRN,
RegularStaffDBRN TemporaryStaffDBRN

SponsoredAffiliate (all types)
- see comments below; current UMOL only subscribers included in SponsoredAffilliates

notes:
- EmeritusFaculty will be covered by the “faculty” roles.
- GSIs, by definition, are students.
- Contractors - are a type of sponsored account.
4 Alumni Alumni
Core Services, with ads
AlumniAA
AlumniDBRN

(Note: starting with FA11 Ann Arbor graduating class unless currently have UMOL)
5 Restricted Restricted Data User No Mail, No Calendar, Some Core, All Additional Services StudentFLNT
FacultyFLNT
RegularStaffFLNT
TemporaryStaffFLNT
6 Alumni Alumni Core Services with ads AlumniFlint
7 [n/a] Terminated, but still in MCommunity directory; remove after 30 days [remain in current sub-org] account suspended Stage 2 of deprovisioning


Transitioning Between Sub-orgs

As an account is transitioned between sub-orgs, we have to consider potential data loss or access to data. The main concern is for users moving from a sub-org with Mail and Calendar services to one without these services. Data tied to a service that is lost in a transition to a sub-org is retained by Google for 30 days and then purged.

For most  users, this is not a concern as there is agreement from Base Restricted units that once a user has received All Services, a job that calculates as Restricted does not remove those services.

Driver logic will transition an account from a Restricted sub-org to an All Services sub-org when eligible roles appear on the MCommunity role. Driver logic will not transition an account from All Services to Restricted without manual intervention since data will be lost in such a transition. When someone moves from a sub-org with Mail and Calendar services to a sub-org without those services, there is a 30-day delay after a notification is sent to the user before the move occurs.

To have an account moved from an All Services sub-org to a Restricted sub-org, please contact the Service Desk (4-HELP).