General configuration

The best practice in RIO is to have a single community that is shared for the Persona’s. The primary reasons are:

• Single community to manage for CMS components etc.

• Chatter Groups can be shared between members (Faculty and Students mainly).

• Many items should be available to multiple personas. - e.g. Shared school event calendar, School News etc.

User management in Communities

Our normal best practice for Applicants is to self register for a community login with their personal email etc. The user will then be assigned a licence from the community or community + licence pool for the Salesforce licence.

For the RIO Licence, we currently use “Site-Wide” licencing in the LMO, so any users will automatically get the RIO licence. The process just needs to set the current Profile, based on the type of user. For the initial applicant they will get the REDU-Student profile, with a contact Role on the contact object set to “applicant” this will be used in the community to identify them. Once an applicant gets a RIO and SF licence, there is no need to update that again. Only the Contact role will be modified when they get accepted into the program. If they are rejected then depending on the SF community user type (Named, vs Login) you may want to add a process to “disable” the user.

Sample of self registration form with mandatory Captcha:

Use Case #1:

Combination of:

• New students directed to self register from the website - Apply Now.

• Directing students who were already converted from a lead to self register.

Process to switch from Applicant to Student

Use Case #1: After student admission fee payment is made.

Admission payment can be manually/automatically tracked to update a status. Once this status is triggered:

1.  Contact applicant type will be updated to student type.
2. Optionally - There are other follow up processes that will take place during this execution such as: Student ID generationStudent email generation.
3. 
   

   1. Update flag to trigger new email account provisioning. This may happen internally or through integration with an email system account.

   2. SF username updated to new student email generated (should happen after Step 2).

      1. Will trigger email notification to student.

Process to Disable User

Option 1: To disable user so that the license (both RIO Ed + SF community) can be released:

1. Review report with rejected applications (e.g. by term).
2. Verify that the contact is not a student.
3. Export contact report in csv.
4. Export user list in csv.
5. Match both exported files by user-contact ID link.
6. Data upload exported user list based on the match.
7. User.Isportalenabled = FALSE (this is equivalent to disabling from the contact level).
8. Revoke RIO Ed license manually.