Force Platform Fundamentals: Student Application Custom Application Development
Universal Technic School (UTS) is considering making a significant investment in a Cloud Computing technology creation tool in areas where it can help them. Student Application Management applied in the Force.com PaaS required are new database system with proper data model. The required data in the application must be to migrate or integrated with the current system to handle the student enrolment and software requirements. The outcome asked by the CIO to present and explain on the use of the Force.com cloud computing platform through a small pilot project or prototype will be demonstrated with the prototype system captures and explanation of each.
A brief background of the UTS that is requesting Force.com PaaS Implementation
This resulted in a new wave of students from the end of 2020 to the end of 2021, when online learning became an alternative go-to solution during Covid-19’s pandemic situation and financial uncertainty triggered demand for its enrollment site. This put an unforeseen strain on the current UTS’s administration system, an IT infrastructure that was never built to manage such a large
(i) volume of new and existing enrolment, particularly during its demand growth. Current students have complained about inadequate enrolment handling and resources, and this issue has risen to the top of the priority list for 2021.
(ii) The specific use-cases for using the cloud Force.com PaaS
Using case diagrams to show the stakeholders for student enrolment application. In the figure below, a student, course administrator, and faculty members have their own access to the portal. The usage of case diagrams were discovered to express the system’s purpose to stakeholders in a more simplified way and to be “interpreted more fully than class diagrams in database”.
Figure showing a basic use case diagram
Figure showing a class diagram for student enrolment system
System Modelling
This section should address the following:
a) Present the Data Model for the Student application (PaaS Application)
Figure 1 — Schemas Data model for student application systems
In the Cloud Force.com PaaS application, a clear definition of cloud data objects, validations, and interface are important to help in solving required of the complexities of systems analysis and architecture. The use-case diagram for the student registration scheme as seen in the schemas, there are three actors: the course coordinator in the course objects, the faculty, and the student. In a use case, they have a simpler graphical description of what the device can do. For a full functional and technological view of the structure, further diagrams and documents are needed.
b) Presentation of the Custom User Profile/s with descriptions of each profile
In the cloud Force.com PaaS application, security of each objects define with the access and authority given to view and edit. To define the clear organisation-wide default, object-level security and tab-level security using custom profiles.
Figure showing organisation-wide default
❏ Student’s access would be restricted and view differently with the faculty member.
Here are some custom objects and its variable that we think are needed to include in the following information of student application. Before student begin this application form, they are to make sure to fill on the required details and have the following documentation on hand, as school will need to refer to them.
In the last part of this form, students will be asked to get notified on the copies of these papers. If you don’t have access to electronic documents, you should submit handwritten copies to the school until your application is considered for a course assessment. After downloading the form, you will be required to pay an enrolment application.
Figure showing the student access settings
❏ Faculty member
In this small university, the faculty in web interface is designed for faculty and course administrators to generate student and their support resources. In the database, course coordinator are also head of their faculty, as responsible to conducting exams, generating and sending exam results to students, and so on. All users (faculty, course administrators, and students) must go through user training (system functionalities) to approve the exam-related queries, while System Administrator and System respectively.
Figure showing the Faculty access settings
c) Data validation and rules on the criteria
This data validation and rules are needed to scope the filter on which users (faculty, administrators, and students) must go through user training (system functionalities).
(i) Data Validation Rules Implementation
1. Validation Rules: Last day of enrolment > starting of enrolment date
Figure showing the course data rule settings
2. Some fields are required to be filled before submitting the form
Figure showing the required form field settings
3. Student applying should be more than 18 years old
Figure showing the student data rule settings
Figure showing snippet of error alert settings
c) Present the Workflow diagrams
Automating workflow would help to process the enrolment in administration. Faculty will receive final enrolment details for courses with instructor names on or before 1 week before the review deadline for the final check, with enrolment beginning in early to mid-February. If there are any mistakes, students will be notified via admin UTS’s email as soon as possible (2 days before the last day of enrolment).
Time-based workflow — creating a workflow rule that sends email alerts automatically are explained below:
1. A workflow task that includes the “Send Reminder Letter” task template
Figure showing task of workflow settings
2. Create the email templates — called ‘’Last day reminder to enrol your course”
Figure showing email created in Force.com
3. Task >Rules > Send email alert
These will remind the students will be notified via admin UTS’s email as soon as possible (2 days before the last day of enrolment). For Summer term, enrolment are made in short date between 3rd February and 14th February.
Figure showing the rule made in Force.com settings
Figure showing on email settings for automated flow
Figure showing on email settings who’s the recipients and test
Figure showing the workflow rule details
d) Prototype System Screens and Description
Create an STUDENT object
● Student ID
● first name
● last name
● Email address
● Gender
● Portal address
● Contact number
● Date of birth
● Age
● Nationality
● Citizenship
Create a COURSE object
● course ID
● course name
● Tutor
● course coordinator name
● Enrolment date
● Last day of enrolment
Create a FACULTY object (FACULTY MEMBERS)
● faculty ID
● faculty name
● faculty member
Figure showing the master-detail relationship (The Faculty Object would be the Master object and the Course Object would be the detail object)
Workflow Test Results:
Try It Out: When students got reminded of the workflow created the “Send Last day Enrolment Reminder Letter” via email. By definition both a workflow rule, which specifies the criteria for when the rule should be executed, and send the email on the triggered time based. Although we can define workflow components in any order, let’s start with defining the workflow rule itself. It’ll save us a couple of clicks a little later when we define the rule’s associated workflow task.
Logo implementation
Logo implemented into the enrollment system, to portray the university look.
Assuming the enrollment system is dedicated to a University in Australia, it requires more implementation to prevent certain abuse in the system and support certain students.
Application spam:
Applicants may want to spam their applications into the system, thus the spam may result from the same person but with multiple versions of the applicant profiles.
Solution to prevent application spam:
In the student’s Object, we may add in another field called passport Id number. Adding this specific field may help identifying specific students and moreover prevent applicants from spamming the enrollment systems, as it is impossible to fake passport details or perhaps a violation.
Special need students:
Some students may require more support which might require notifying the faculty and letting the staff in charge to prepare. Thus in the student’s Object, there should be another field (maybe named special needs) which allows the faculty to know the overall special students, and determine the amount of support and resources they should allocate to them.
HECS-HELP:
Regarding students’ payment towards university, universities should have a notification system to notify students who can obtain HECS-HELP on instructions of getting it. Solution: Automated Email system workflow:
While editing the rules, the requirement for sending the email would be sending all students who are permanent residents or an Australian. Thus Student’s Object may require adding another field to prove they have permanent residency.
Course requirements:
Some courses may have course prerequisites which means some courses require students to finish some courses previously first in order to enrol. Furthermore courses are specifically allocated in specific seasons.
Possible Solution:
Add new fields in Course Object which can help both faculty and students to identify the specific course. The possible new fields that should be added are Year and Season, this is required so that the students can be identified which year and season he or she has completed the course, which can help course prerequisites, and also can be implemented towards the enrollment planning system. Furthermore, with these new fields, faculty can also identify the responsible staff related to the course at a specific time and further help planning and recording resource allocations and courses.
Student Enrollment Status
With a lot of applicant entries, faculty members should know the details of which applicant has been rejected, and focus on the students which they accept, furthermore allowing them to reconsider accepting applicants who are re-applying to the university.
Solution:
Add a field in student’s Object, for easy identifications. Status in this field can be, rejected, pending and accepted, furthermore potentially more statuses can be added in the future to identify whether the student has paid their education fees to the university. Such identifications can be implemented to help categorise applicants reapplying, and help faculty members to recheck their notes on reasons rejecting the previous application.
In Conclusion, implementing future PaaS potential addition works may present new challenges, therefore the organization should be cautious and aware of the system’s potential and weakness. Challenges may occur to stall or hinder the university enrollment development, therefore new fields and new workflows should be implemented or considered to be implemented for further improvement. Such implementation can benefit both faculty members facilitating course outlines and students to correctly identify the correct course enrolled.
References:
McGuire, C, Roth, C, Carroll, D, Tran, N, Gross, A & Leszek, A. 2008, Force platform fundamentals: An Introduction to Custom Application Development in the Cloud, 1st ed
