Secure Message Center

Chris Malek designed and implemented a custom Secure Message Center PeopleTools bolt-on for National University (NU). This module was turned on in July 2011 and has already sent close to 1,000,000 messages. The functionality implemented at NU was designed to be flexible and user friendly for the students who receive the messages and functional users who post messages. Additionally, a PeopleCode API was added so that batch processes and online pages could programmaticly post to the Message Center in response to different business events. The primary user base was students. However, the design was created to be flexible so that messages could be sent to any PeopleSoft user.

Problems Being Solved

What problems did the Secure Message Center solve?

  • It gave the university the ability to send sensitive information to students that could not be sent via email.
  • It allowed faster communications to students.
  • It gave the university the ability to track if and when a student read a message.
  • It gave the university the ability to retract messages before and after they are read.
  • It gave the university better auditing of historical communications to students.
  • It reduced the number of mail merge mailings to students.

Project Goals

What where the high level goals of the Message Center module?

  • Provide a user-friendly secure place for the university to send student specific messages. These messages were previously being sent using mail merge and the USPS.
  • Allow for ad-hoc and batch messages to be easily created, updated, retracted and monitored by a staff member without getting IT involved.
  • Allow multiple vectors for messages to be created including data entry, PeopleCode, file upload, and query results.
  • Messages should have some basic tracking counts like the number of messages, read, un-read, etc
  • The message center user interface should be very intuitive to the student and should mimic the simple functionality found on all on-line banking websites.

Self Service Functionality

The student facing piece of the Message Center is the “My Message Center” self-service page. This page is designed to look very similar to other message centers that students use at their banking or credit card websites. It is designed with the following functionality in mind:

  • Students should see an alert on their home page that says “You have xx unread messages in your message center.” This is accomplished with the My Alerts Module.
  • The interface for the student should be very simple to use and require no job aids or instructions.
  • Students should be able to read messages and then “archive” them, which will remove the message from their inbox but allow it to be retrieved later if needed.
  • When a student views the detail of a message, it will be automatically marked with a read date and time. A student cannot mark a message as unread.
  • If a message was sent with an expiration date, it will automatically be hidden from the student after the message expiration date.
  • If the staff member has included attachments like a PDF, the student should be able to download them.
  • HTML formatting will be allowed in the message so different text styling and links can be used to enhance the message.

Staff Functionality

The project delivered the following high level functionality for the staff members who configure and send messages:

  • A page where new messages can be created in the Message Center and existing ones maintained.
  • A staff view into a student’s “Message Center.” This allows a staff member to see exactly what the student will see to handle support calls.
  • A batch process to run SQL from the query manager and automatically create Message Center entries based on the query results.
  • A batch process to notify students who have un-read messages in the message center using configurable notification rules.

Message Center Creation and Maintenance

There is one page that allows staff members to create and administer messages. This page is designed for a knowledgeable functional user who understands data security and communication policies at the university.This page is not meant to be given out to front line data entry staff who may not have this knowledge.

The following is a high level overview of the Staff facing Message Center (MC) functionality:

  • A “Message ID” (MC_ID) can be created which can contain many recipients under that MC_ID. The MC_ID is a unique id that identifies the cohorts of a particular message. A MC_ID can have one or many recipients.
  • A MC_ID is tagged with a 3c “Admin Function” for data security purposes to secure messages from different groups of staff members viewing messages.
  • Fields are provided for notes by the staff member for historical purposes and the student will never see these notes.
  • A MC_ID is marked with a “from” MC department from a new MC Department setup table.
  • A MC_ID is set to a status that determines if it is viewable by the student. The statuses are:
    • Draft – A work in progress. Students cannot see messages in this status.
    • Canceled – A message that was either in draft or retracted that needs to be removed from the queue.
    • Published – Messages that are in this status are viewable by the student.
    • Retracted – This is used for messages that were published but need to be removed from the student’s view.
    • Template – Used to mark a MC_ID as a template, which can be cloned by other users. Additionally, the PeopleCode API relies on a template to generate messages. This template allows a functional person to update message content without any code changes.
  • An MC_ID can have a start and end date so messages can be set to “automatically show” in the future or “automatically expire.”"
  • A free form “subject line” is given for a message just like an email message.
  • The message content can be either plain text or HTML.
    • The message center content has the ability to “merge” data fields very similar to a mail merge in a word processor. The text of the message is marked up with special references to merge fields and they are substituted at run-time.
  • Shared attachments can be added to the message. For example, if a PDF needs to be distributed to 100 people, then you can upload that PDF to the message center once. All student ids attached to the message can view the same attachment.
  • A staff member can upload a “mail merge file” that can be delimited in several different formats including comma, semi-colon or pipe. This upload file must contain the student id and up to 15 different mail merge text fields (254 characters each in length). All the merge fields are optional.
  • The page has a “preview” area where the staff member can test what both the HTML (if used) and merge fields look like to find data entry mistakes prior to publishing.

Below are a few screenshots of the setup page.

Query Import to Message Center

A batch application engine was created that allows a functional analyst to run an existing PeopleSoft Query Manager query and have it import into the Message Center with the option of automatically publishing. This allows functional users to easily maintain SQL changes and create ad-hoc queries and quickly push the results into the message center without IT support or code changes. The process relies on a “template” message which it clones. This process can be setup to run on a recurrence to automatically post new business events to the message center.

Notification Process

A batch process was created to notify students via email that they have unread messages in the message center. This is designed to run once per day and will do the following:

  • Find the set of student ids that have unread messages
  • Determine if the student needs to be notified again based on the Message Center Department notification rules and past notification history for the Message ID.
  • For students’ who need to be notified that they have unread messages, an email is sent with a generic text that will say something similar to: “You have 5 unread messages in the Message Center. Please login to the student system to view them.”

Department Setup

A new “Department” Message Center setup table was created, which is isolated for use only by the Message Center. This is not in any way tied to any other “department” definition that existed in the HR or Finance systems. This was used to clearly define who the message is coming from at the university in the eyes of the student. If we used HR or Finance departments, they may not make sense to a student as the descriptions on the delivered setup tables are likely setup for internal consumption by staff. Additionally, the HR and Finance department values often revolved around headcount and budgeting, which means nothing to the student.

The functionality of this new MC Department table is as follows.

  • New MC Departments can be added and the descriptions of existing ones can be changed.
  • You cannot delete departments from here because it would currupt historic messages.
  • The notifications frequency can also be controlled from here. There is a batch process that notifies students via email that they have unread messages in the message center. You can setup notifications like the following at the “department level.”
    • Notify once per day for a total of 5 notifications for the specific department.
    • Notify once per week for a total of 2 notifications for the specific department.
    • Do not ever notify for the specific department.

PeopleCode API Functionality

We also created a simple PeopleCode API to create messages. This allows batch processes (Application Engine PeopleCode) and online pages to programmatically trigger messages in the message center. This API removes the complexities of the data structure and provides an easy to use interface so that message center messages can be posted with a few lines of PeopleCode. This API relies on a message “template” which is just an entry in the Message Center setup with a status of “template” and tagged with a unique “template identifier” string.

In the code sample below, a PeopleCode snippet is included to show creating a new message center message that has two student ids as recipients and 3 merge fields.

Local MSG_CENTER:messageCreator &mc = create MSG_CENTER:messageCreator("CRM_UNIT_TEST", True);

If &mc.templateFound Then
    Local array of string &aMergeData;

    &aMergeData = CreateArrayRept("", 0);
    &aMergeData.Push("mail merge value 1 ");
    &aMergeData.Push("mail merge  2 ");
    &aMergeData.Push("mail merge  3 ");

    /* Add first student id id */
    If &mc.addRecipient("000473272", &aMergeData) Then
         /* Success */
    Else
          /* Probably not a valid emplid, could not be added */
    End-If;

    /* Add first student id id */
    If &mc.addRecipient("021911950", &aMergeData) Then
         /* Success */
    Else
          /* Probably not a valid emplid, could not be added */
    End-If;

    if &mc.save() then
        &newMessageID = &mc.NewMessageID;
    else
        /* something bad happend */
        /* check &mc.errorMessages */
    end-if;

The API also has full support for attaching files to the message that may be created at run-time. In addition to the full 15 merge fields, there is also an additional “long” field that can be populated by the API. The API also allows the code to fully change and append to the message text, subject and date fields.