Content Comparison

...

• Security and Access Management
  • Update permissions on all existing objects to ensure proper access based on role and need
    • Realms
      • Add Advising realm to all advising specific objects
        • Queries, Forms, Mailings
      • New objects should have appropriate realm assigned going forward, particularly new Alumni elements
• Opt-outs
  • 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
      • SPS No Email Solicitations (Y/N)
      • SPS No Event Invitations (Y/N)
      • SPS No Newsletters (Y/N)
      • SPS No Reunion Outreach (Y/N)
      • SPS No Contact (Y/N) - Since only emails are sent, this is likely unnecessary
      • SPS No Solicitations (Y/N) - Since only emails are sent, this is likely unnecessary
    • 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, but no follow-up email communication
    • Need mechanism to allow contacts to change their preferences (e.g., opt back in at a later date)
• Populations
  • 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
        • This field needs to be updated from the SIS feed to reflect any programs that have degrees associated with them for the alumni
      • Update the populations for alumni to grab the program from the new field instead of the program of study
      Students that have more than one program will only show in the one labeled as the current Program of Study; need to add a field to track historic programs, or to add the programs to the academic history for segmentation
      • Add the values from the graduated programs to the various student dashboards (alumni, current, former)
• Landing Page
  • Create separate homepage widgets for the Alumni realm highlighting relevant information
    • Actual widgets TBD
• Communications / Deliver
  • Filters
    • Document existing filters that can be added to recipient list queries to refine the audience
    • Consider adding new filters or data points based on additional criteria (likely next cycle)
  • Ensure that all restrictions (opt-outs) are honored across all communications
    • This should be as systematic as possible to ensure there are no accidental sends to opt-outs
  • Ensure that the default sender alias is not defaulting to spsadvising for any alum/program comms
    • This cannot be set per user, and will require control through process documentation
  • Use the Designer functionality for all standard communications
    • Document workflows for mailing creation, recipient list selection, queuing for review, and sending
    • Test and validate send privileges for user roles
  • Components 
    • Coordinate with Web Dev team for next phase of component development (likely for next build cycle)
      • Focus on new designs, flexible branding, and responsive functionality
  • Templates
    • Create a simple universal template that can flex its layout depending on the components in use
  • Chrome Extension
    • Plan for distribution to users, and document installation process
    • Refine functionality for improved usability
      • Better input for Events List component
      • Consider methods for getting images into the Slate library through the extension form
  • Model out the guardrails to ensure that emails are not sent directly, but go to the review queue for the Alumni team to review
    • If there is a way to only require this when there are Alums in the recipients list, that would be great, but may not be possible
• Database Ops / Feeds
  • Automate incoming data feed per technical specifications
    • From Athena (in development)
      • Requires opt-out data fields for all Athena categories that apply
      • Person-scoped fields
        • Athena ID
  • Automate outgoing data feed per technical specifications
    • To Athena
      • SPS opt-out values
      • Universal identifier (TBD - Athena ID, CUID, or UNI)

...