...

Requested Features

Current Cycle 

Release FY24.1.0 [

...

December 2023]

Features to Complete

...

• Automate outgoing data feed per technical specifications
  • To Athena
    • SPS opt-out values
    • Universal identifier (TBD)
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
• Forms
  • Capture granular opt-in and opt-out for SPS communications
    • Person-scoped fields
      • Athena ID
      • SPS No Contact (Y/N)
      • SPS Do Not Email (Y/N)
      • SPS No Solicitations (Y/N)
      • SPS No Email Solicitations (Y/N)
      • SPS No Event Invitations (Y/N)
      • SPS No Newsletters (Y/N)
      • SPS No Reunion Outreach (Y/N)
    • Form should not require login, but can only be accessed using a secure link specific to the user account
    • Align communication categories with Athena, and require designation in all communications sent through Slate
      • See categories shown above in fields
    • Page showing selections should be displayed on submit, but no follow-up email communication
    • Form should 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; how do we want to handle isolating only alums in a particular program, in the population or a student status field at the program level?
    • 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
• Landing Page
  • Create separate homepage widgets for the Alumni realm highlighting relevant information
    • Actual widgets TBD
• Communications / Deliver
• 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 unsubscribe link for all comms goes to the custom opt-out form
• Ensure that all "Slate" branding elements, including text in footers and opt-out messages, are changed to reflect SPS
• Ensure that the default sender alias is not  defaulting to spsadvising for any alum/program comms
Use the Designer functionality for all standard communicationsComponents 
• Create components for all of the potential elements that are included in a standard mailing
• Use existing templates to model the first round of components
  • {List initial set of components by name here}
Communications / Deliver
• Filters
  • Document existing filters that can be added to recipient list queries to refine the audience
• 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
• 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

Features to Consider

• 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)
• Communications / Deliver
  • Filters
    • Consider adding new filters or data points based on additional criteria (likely next cycle)
  • Components 
    • Coordinate with Web Dev team for next phase of component development (likely for next build cycle)
      • Create templates for each type of message that requires a specific layout
        • Begin with the regular Alumni office mailings
      • Create a simple universal template that can flex its layout depending on the components in use
      • Chrome Extension
        • Update the input form for collecting the content to inject into the selected component with any required customizations
      • • Focus on new designs, flexible branding, and responsive functionality
  • Landing Page
    • Create separate homepage widgets for the Alumni realm highlighting relevant information
      • Actual widgets TBD
  • Communications / DeliverHow does Graduway data (when implemented) fit into the Slate implementation, if at all?
    • Create template(s) in simple HTML to accommodate truly unique designs that fall outside of the designer components
      • May require content blocks for shared/reused messages
    • 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

  Features to Consider

  • • Templates
      • Create a simple universal template that can flex its layout depending on the components in use

  Features to Review in Future Slate Updates

  ...

  • 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
      • 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.  
      • Opt-out functionality has been thoroughly tested. In message statistics, people who are unsubscribed to the message group are excluded from the "Sent" count and included in the "Skipped" count.
  • 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

  Previous Releases