Content Comparison

...

• Security and Access Management
  • Create a security model that supports three unique realms to serve the three utility functions
    • Advising
    • Alumni
    • Programs
  • Create roles to control access to functionality based on business function
    • Alumni Operations
    • Program Operations
  • Update permissions on all existing objects to ensure proper access based on role and need
    • Realms
      • Add realm column to object views where realm can be assigned
  • Create security documentation to define what permissions to apply to future objects based on the defined roles and realms
    • Include maps to existing objects for current state
  • Add populations to user profiles based on security requirements
    • Populations should include Program or Alumni Operations roles depending on the user
      • Alumni team = Alumni Ops
      • Program teams = Program Ops
• Opt-outs
  • Deactivate the default unsubscribe message group - Allow Unsubscribe (default)
  • Capture granular opt-in and opt-out for SPS communication categories
    • Use built-in opt-out workflow with defined message groups
      • SPS Do Not Email (Y/N) - full organization opt out
      • SPS No Email Solicitations (Y/N)
      • SPS No Event Invitations (Y/N)
      • SPS No Newsletters (Y/N)
      • SPS No Reunion Outreach (Y/N)
    • Align communication categories with Athena, and require designation in all communications sent through Slate
      
      • This can only be controlled through workflows and training when messages are created
    • Page showing selections should be displayed on submit, with no follow-up email communication
    • Need mechanism to allow contacts to change their preferences (e.g., opt back in at a later date)The bottom of each message contains a link for the user to unsubscribe to that message group. Clicking that links takes them to a page where they can opt-in/out of ALL message groups (not just the one for which they came). This allows them to either opt-in to or opt-out from messages from any group.  
• Populations
  • Create the populations for each of the defined population groups (Degree ONLY for now)
    • Approved Alumni, Current Students, Former Students
      • Each category per program, and one set of three for All Programs
      • Assign each Program-centric population to the Academic Director (for targeted programs - Wealth and Insurance)
      • Assign the All Programs groups for Alumni and Current to Alumni Relations (do not assign former students - may need to change)
  • Create population rules to assign records to the appropriate population(s) based on defined criteria
    • Use the same naming convention as populations for consistency
  • Edge Cases
    • Alumni populations are based on alumni status, some program students will be alums from another program while an active student in a current program, or simply grads from multiple programs
      • Requires a new field that can have multiple values, one for each graduated program (graduated_programs)
        • This field needs to be updated from the SIS feed to reflect any programs that have degrees associated with them for the alumni
        • Update query and source format to load new field with history, and pass new grad values going forward
      • Update the populations for alumni to grab the program from the new field instead of the program of study
      • Add the values from the graduated programs to the various student dashboards (alumni, current, former)
        • Update underlying queries to include new field values
• Queries
  • Create queries based on populations and ensure permissions adhere to security model (realm and roles)
    • Approved Alumni for My Programs
      • Will include any Alumni from the current user's population base
    • Current Students for My Programs
      • Includes any current students from the current user's population base
    • Former Students for My Programs
      • Includes any former students from the current user's population base (non-alumni)
• Communications / Deliver
  • Ensure that all "Slate" branding elements, including text in footers and opt-out messages, are changed to reflect SPS
  • Components 
    • Create components for all of the potential elements that are included in a standard mailing
      
      • Use existing alumni newsletter to model the first round of components
        • Call to Action - Centered
        • Divider
        • Events List
        • Footer
        • Header
        • Image - Full Width
        • Section Header
        • Story - Side-by-Side
        • Story - Campus News
        • Story - Class notes
        • Sub-header
        • Text Block - Full Width
        • Update Contact Info
  • Templates
    • Create template for the alumni newsletter mailing
  • Chrome Extension
    • Update the input form for collecting the content to inject into the selected component with any required customizations

...