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)
- 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)
- 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.
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.
||MCommunity Institutional Roles
||All Services, no ads
Regardless of restricted flag or Flint roles. This state trumps the restricted flag.
||Restricted Data User*
- includes Sponsored Accounts from units with restricted data use
|No Mail, No Calendar, Some Core, All Addtional Services
* 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.
||Ann Arbor Employee (Faculty, Staff, Temps, Emeritus)
- includes regular sponsored accounts with services
|All Services, no ads
SponsoredAffiliate (all types)
- see comments below; current UMOL only subscribers included in SponsoredAffilliates
- EmeritusFaculty will be covered by the “faculty” roles.
- GSIs, by definition, are students.
- Contractors - are a type of sponsored account.
||Core Services, with ads
(Note: starting with FA11 Ann Arbor graduating class unless currently have UMOL)
||Restricted Data User
||No Mail, No Calendar, Some Core, All Additional Services
||Core Services with ads
||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).