Technical Details
Current Release Version:
Release Date:
Security Roles: SPS Alumni
Requested Features
Current Cycle
Release FY24.1.0 [November 2023]
Features to Complete
- Database Ops / Feeds
- Automate incoming data feed per technical specifications
- From Athena (in development)
- Requires opt-out data fields for all Athena categories
- New field for Athena UID
- From Athena (in development)
- Automate outgoing data feed per technical specifications
- To Athena
- SPS opt-out values
- Universal identifier (TBD)
- To Athena
- Automate incoming data feed per technical specifications
- Security and Access Management
- Create a security model that supports three unique realms to serve the three utility functions
- Advising
- Alumni
- Communications (for Slate+SPS initiative)
- Create roles to control access to functionality based on business function
- Update permissions on all existing objects to ensure proper access based on role and need
- Create security documentation to define what permissions to apply to future objects based on the defined roles and realms
- Add populations to users based on security requirements
- Create a security model that supports three unique realms to serve the three utility functions
- Forms
- Capture granular opt-in and opt-out for SPS communications
- 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
- Categories provided in Athena integration docs
- Page showing selections should be displayed on submit, but no follow-up email communication
- Ensure that all restrictions are honored across all communications
- Capture granular opt-in and opt-out for SPS communications
- Populations
- Create the populations for each of the defined population groups
- Approved alumni, current students, former students
- Each category per program, and one set for all programs
- Approved alumni, current students, former students
- 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
- Create population rules to assign records to the appropriate population(s) based on defined criteria
- Use the same naming convention as populations for consistency
- Create the populations for each of the defined population groups
- Queries
- Create queries based on populations and ensure permissions adhere to security model (realm and roles)
- Landing Page
- Create separate homepage widgets for the Alumni realm highlighting relevant information
- Actual widgets TBD
- Create separate homepage widgets for the Alumni realm highlighting relevant information
- Communications / Deliver
- Use the Designer functionality for all standard communications
- Create components for all of the potential elements that are included in a standard mailing
- Create templates for each type of message that requires a specific layout
- Create a simple template that can flex its layout depending on the components in use
- 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
- Use the Designer functionality for all standard communications
Features to Consider
- How does Graduway data (when implemented) fit into the Slate implementation, if at all?
Features to Review in Future Slate Updates
- Not started
Features Ready for Release
- Not started
Add Comment