Versions Compared

Version Old Version 27 New Version Current
Changes made by

Bryon Vaughn

Bryon Vaughn

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Requested Features

Current Cycle 

Release FY24.1.0 [

...

December 2023]

Features to Complete

...

  • From Athena (in development)
    • Requires opt-out data fields for all Athena categories
    • Person-scoped fields
      • Athena ID

...

  • 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
  • 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; 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)
        • Focus on new designs, flexible branding, and responsive functionality
  • Landing Page
    • 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 ExtensionUpdate the input form for collecting the content to inject into the selected component with any required customizationsseparate 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