Before Working With Student Alerts

Before working with Student Alerts, administrators must perform the following activities:

Customize Options in the Alert Reason and Alert Reason Details Fields

Note: In the Student Alert form, options that can be selected in the fields Alert Reason and Alert Reason Details must be customized before users work with the feature. While it is required to modify the display values in these fields based on an institution's usage, it is recommended not to perform these updates frequently.

Administrators must perform the steps in either of the following scenarios:

Option sets will need to be created for the Alert Reason and Alert Reason Details fields.

  1. In your default solution, save and publish option set values for the fields Alert Reason and Alert Reason Details.
  2. In the Dependent Option Set Manager, select the above solution and then type the schema and display name of the web resource you want to create.

  3. Click to complete the creation of the web resource. The following confirmation message will be displayed.

  4. Click OK to view the Edit Configuration form.

  5. Select an entity and a form and then click .
  6. (Example) In the Dependencies area, the following options available in the parent field (Alert Reason) will be available for configuration:

    Note: The same value in the Alert Reason Details field can be set for multiple values of the Alert Reason field. To enable this behavior, clear the option Strict Selection.

  7. For each of the above options, selections from the Alert Reason Details field can be made in individual drop-downs.
  8. Preview your selections in the preview area and then click Save Configuration.

OR

These steps must be performed to inherit values of the Alert Reason and Alert Reason Details fields from the previous version into the current version.

  1. Click Upgrade from Dependent OptionSet Generator.
  2. Click Upgrade.
  3. In the main menu, click Clone the JSON Web Resource to create a copy of the default web resource.
  4. Click Remove Configuration from Forms to remove the original web resource from all forms
  5. Click Edit Configuration to associate the new cloned web resource with selected forms

Enable Flows for Student Alert

Review the following flows to ensure that the flows needed for campus operations are enabled.

S. No. Flow Name Description
1. Student Alert – Associate Student Alert to Case
On creation of a new case with a new student alert record, the Origin of Case and Type fields are updated to Student Alert. The Case field in the associated student alert record is also updated with a link to the case record. On editing an existing case where a new student alert record is created, this flow updates the field Type as Student Alert and the field Origin of Case as Student Alert if it was blank previously.
2. Student Alert – Create Case from Alert
A new case record is created from a student alert record. Both records are associated.
3. Student Alert – Create new if low Retention Score If the student's current retention score drops below the configured threshold, a new student alert record will be created.

Note: In this flow, administrators must update the configured retention score and include a valid Alert Reason value.
4. Student Alert – If Invalid Update Alert Status and Status Reason If the student alert is invalid, the field Status is set to Inactive and the field Status Reason to Cancelled.
5. Student Alert – On Case Cancelled or Resolved Update Alert Status and Status Reason In a case, if the Status is set to Cancelled, update the associated student alert’s Status to Inactive and Status Reason to Cancelled. If the Status of the case is set to Resolved, update the associated student alert’s Status to Inactive and Status Reason to Resolved.
6. Student Alert – Set Owner as Student’s Advisor

On creation of a student alert record, update its Owner field with the most recently modified student's advisor in associated success network records.

If no advisor is found, an email is sent to the user configured in the Student Alert Business Process Notification field in the Default Configurations page.

On receiving the notification, the recipient can assign a faculty member as an advisor or equivalent role to the student.

Note: When this flow is enabled, ensure that the Notification - Send Email flow is also enabled so that the notification email is sent successfully.
7. Student Alert – Student and Submitter cannot be the same

When creating a student alert, the Alert Submitter and Student lookup fields are compared and one of the following actions take place:

  • If both fields have the same value, the flow locates the contact record of the creator and sets the contact in the Alert Submitter field.

  • If no record is found, the Alert Submitter field will be blank and an email is sent to the user configured in the Student Alert Business Process Notification field in the Default Configurations page.

On receiving the notification, the recipient can create a contact record for the user who must be assigned as the student alert submitter.

Note: When this flow is enabled, ensure that the Notification - Send Email flow is also enabled so that the notification email is sent successfully.
8. Student Alert - Contact to Submitter Match On create of a student alert record, if the Alert Submitter field is blank and Submitter's First Name, Last Name, and Email Address values are available, then the system will look for an exact match against all active Contact records.

If an exact match is found the Alert Submitter field will be populated, however, if an exact match is not found or more than one match are found then the Alert Submitter field will be left blank.
9. Student Alert – Update Submitter Properties On update of the Alert Submitter lookup field, all Submitter properties on the student alert form will be updated with data from their contact record.
10. Student Alert - Notification to Submitter that Alert was Created

In a new student alert record, if the value in the Alert Source field is not Manual Entry or Generated by System Data, this flow will send an email notification to the submitter.

This flow is enabled by default.
11. Student Alert - Notification to Submitter that Alert was Resolved On updating a student alert record where the Status Reason is set to Resolved, if the Alert Source is not Manual Entry or Generated by System Data, an email notification will be sent to the submitter.

This flow is enabled by default.

Note: For notification emails to be sent, ensure that the following flows are enabled:
  • Student Alert - Submitter Notification Details
  • Notification - Send Email
12. Student Alert - Submitter Notification Details

This flow sends notifications to the submitter on creation and resolution of student alert records.

The email content or any error string, the sender's email GUID or the sender queue's GUID, etc. can be reviewed and updated in this flow.

Also, email activity will be deleted from the recipient contact's timeline by default. This setting can be changed.
13. Student Alert - Notification to Student that Alert was Created

In a new student alert record, if the Visible to Student field is Yes, an email notification will be sent to the student.

This flow is disabled by default and must be enabled.

Note: For notification emails to be sent, ensure that the following flows are enabled:
  • Student Alert - Submitter Notification Details
  • Notification - Send Email
14. Student Alert - Notification to Student that Alert was Resolved

In a student alert record, if the Visible to Student field is Yes and the Status Reason is Resolved, an email notification will be sent to the student.

This flow is disabled by default and must be enabled.

Note: For notification emails to be sent, ensure that the following flows are enabled:
  • Student Alert - Submitter Notification Details
  • Notification - Send Email
15. Student Alert - Student Notification Details

This flow sends notifications to the student on creation and resolution of student alert records.

The email content of the notification or any error string, the sender's email GUID or the sender queue's GUID, etc. can be reviewed and updated in this flow.

Also, email activity will be deleted from the recipient contact's timeline by default. This setting can be changed.
16. Notification - Send Email This is a generic notification flow that can be used to send email notifications from Dynamics 365. The flow is manual and will run only when called by another process or flow. Following parameters must be passed to run this flow:

  • ToEmail (required) – Type the recipient's email address.

  • Subject (required) – Type the subject of the email

  • EmailBody (required) – Type the email content.

  • DeleteAfterSend (default is No) – Select Yes if email activity must be removed after sending the email. so that it is not visible in activities.

  • Send From Queue (default is No) – Select Yes or No.

  • FormId (optional) – Type the sender’s user id (GUID) or queue id (GUID) if a specific user or queue must be used as the sender.

    If a user ID or queue ID is available, it must be configured to allow sending emails. If both are not provided, the system will check if an email address configured in the Email Dispatcher field (Default Configuration > General) will be used to send email notifications. If not, the calling flow owner’s email address will be used to send email notifications.

    If the passed in information cannot be used to successfully queue the email to be dispatched, an error message will be passed to the calling flow. A maximum of 5 attempts will be made to dispatch the email. The mailbox used to send the notification can also monitor the success rate of the emails.

Note: Users can view dispatched notifications in the Student Alert Notifications tab in the student alert record. Additionally, records in this tab can be queried and viewed based on their delivery status.

Enable Workflows for Student Alert

Ensure that the following workflows are enabled:

S. No. Workflow Name Description
1. Student alert on create - update alert name and student properties This workflow will run when a student alert record is created. It will update student fields and the name of the student alert record.
2. Student alert on update - update student properties This workflow will run on an update of the Student field and will update other student fields.
3. Student alert on update - update alert name. This workflow will run on an update of the fields Alert Reason, Student First Name and Student Last Name and will also update the name of the student alert record.
4. Case Student Alert - Validate Student On create or update of a Case, the workflow validates if the Student field in the associated Student Alert record is identical to the value of the Submitted for field in the Case record.

In a case record, this workflow validates if the Submitted for field in the associated Student Alert is identical to the value of the Submitted For field in the case.
5 Student Alert - Update resolution date on status change to resolved When a Student Alert record is updated and the status reason is set to resolved, the workflow will timestamp the resolution date and time as well.
6 Student Alert Case - Student Validation On create or update of a Student Alert, the workflow validates if the Submitted for field in the associated Case record is identical to the value of the Student field on the Student Alert record.

Activate Business Rules for Student Alert

Ensure that the following business rules are activated:

  • Student Alert - Lock Alert Reason
  • Student Alert - Lock Alert Source
  • Student Alert - Lock Student
  • Student Alert - Lock Submitter
  • Student Alert - Lock the Create Case Field
  • Student Alert - Require Reviewer Info
  • Student Alert - Student not required if Invalid

Option 1: If the institution wants to use the Send Action

Copy the flows, and save and publish the copied flows to the unmanaged solution in the institution’s implementation.

Option 2a: Using Microsoft Exchange

  1. In the copied flows, add connection credentials for the user account that will be used by Exchange to send email notifications.
  2. Save the copied flows and add them to the unmanaged solution in the institution’s implementation.
Pros Cons
Is a best practice as the push notification is in the flow logic. None

Option 2b The Institution does not use Exchange

Secure a free Office 365 A1 for faculty license and assign the license to a generic new user for a do-not-reply email account. Use these credentials to connect with Outlook in Office 365. Follow procedures of Option 2a.

Option 3 The institution uses Gmail or any other mail system and does not want to use any of the above options

  1. In the copied flows, remove the Outlook email action and use the SMTP flow connector instead – see image below. Administrators can use the same SMTP connection that is used for TPC portal.
  2. Add these copied flows to the unmanaged solution and then publish the institution’s production environment.
Pros Cons
  1. Uses the same credentials set up for the Portal.
  2. Limited additional effort
None