Government Scholarship Management System

The Client

A government ministry that manages scholarship programs for university students. The program opens every semester and receives thousands of applications. Multiple coordinators, managers, and approval levels are involved in the selection process.

The Problem

Before this system, the scholarship process ran on spreadsheets, phone calls, and email.

• Students submitted applications by email with attachments
• Coordinators tracked everything in Excel – who applied, what documents were received, who needs an interview
• Interview scheduling happened over phone and email
• Approval decisions passed between managers through forwarded emails
• Accepted students reported their activity hours manually
• The team managing the process was large, and things regularly fell through the cracks

Every semester, the same chaos repeated. The ministry needed a system that would run itself – open when the semester starts, collect applications, route them through approvals, and require minimal maintenance between cycles.

What We Built

Three connected portals on Salesforce Community, plus a full backend workflow:

1. Student Application Portal

Students reach the application through the ministry’s website. The process:

1. Authentication – 2FA via email. No Salesforce login required – students authenticate as guest users through a secure identification flow.
2. Dynamic application form – Built as a Screen Flow embedded in the Community site. The form adapts based on answers – different fields, different required documents, different validation rules depending on the student’s situation (degree type, institution, financial status).
3. Document upload – Students upload required documents. Which documents are required depends on their specific answers. The system won’t let them submit until all relevant documents are attached.
4. Digital signature – Required documents are signed on-screen using Titan eSign, triggered automatically based on the application data.
5. Submission and tracking – After submission, the student receives automated email confirmations. If additional documents are needed later, the system sends a targeted email requesting exactly what’s missing.

2. Coordinator Portal

Scholarship coordinators log into a dedicated portal with tabbed navigation:

• New applications – Incoming submissions ready for initial review
• In progress – Applications being processed, with all uploaded documents accessible inline
• Interview scheduling – Coordinators send automated emails to students with a link to a scheduling tool. Interviews happen remotely – no physical meetings needed.
• Pending approval – Applications forwarded to the next approval level
• Approved/Rejected – Final decisions with full audit trail

Each coordinator only sees applications assigned to them. The portal is role-based – coordinators, scholarship managers, and program directors each see exactly what’s relevant to their level.

3. Accepted Students Portal

Students who receive the scholarship get access to a separate portal where they report activity hours and locations. This replaced a manual paper-based reporting process.

Approval Hierarchy

The approval chain has three levels:

1. Student coordinator – Reviews application, conducts interview, makes initial recommendation
2. Scholarship coordinator – Reviews recommendation, validates eligibility, forwards to management
3. Scholarship director – Final approval or rejection

Each level was implemented using Salesforce Profiles, Permission Sets, and Sharing Rules. The native Salesforce approval process handles the routing between levels. When the final decision is made, the student receives an automated email with the result.

Technical Architecture

Salesforce Side

• Data model – 7 custom objects: Campaign (semester), Account, Contact, Applicant, Application, Interview, and Time Report. Each scholarship cycle is a Campaign – when it becomes active, the portals automatically reflect the current cycle.
• Community (Experience Cloud) – Guest user profile for student applications. Authenticated profiles for coordinators and accepted students, each with specific permission sets.
• Screen Flows – The application form is a multi-step Screen Flow with conditional visibility, field validation, and document upload components. The flow handles complex branching – date validations, document requirements based on prior answers, and eligibility checks.
• Approval Process – Native Salesforce approval with three levels, automated email notifications at each stage.
• Automated emails – All communication is triggered by record changes and field values. No manual emails. Missing document reminders, interview invitations, approval notifications, acceptance/rejection letters – all automated based on rules.

Frontend

• Custom CSS – The Community pages were styled with custom CSS to match a Figma design. Clean, accessible UI suitable for a government-facing application.
• Titan eSign – Document signing triggered during the application flow based on conditions in related records.
• Scheduler integration – Interview scheduling via automated email with a direct link to a scheduling tool.

Design Decisions

Two decisions made this system sustainable long-term:

Campaign-driven cycles. Each semester is a Salesforce Campaign. When a new Campaign is activated, all portals automatically switch context – new applications go to the current cycle, coordinators see the current batch, reports filter by the active campaign. No manual configuration needed between semesters.

Everything dynamic. The form conditions, document requirements, email triggers, and approval routing are all data-driven. When requirements change (a new document type, a different eligibility rule), the team updates a record – not code. This was a conscious decision from day one: build it once, maintain it through configuration.

Results

Technology Stack

• Salesforce Experience Cloud (Community) – Three portals: student application, coordinator management, accepted student reporting
• Salesforce Screen Flow – Dynamic multi-step application form with conditional logic
• Salesforce Approval Process – Three-level hierarchical approval chain
• Profiles, Permission Sets, Sharing Rules – Role-based access control across all portals
• Titan eSign – Document signing triggered by application data
• Custom CSS (Figma) – Government-standard accessible design
• Automated Email – All communications triggered by data changes and workflow rules

What We Learned

Government projects have a reputation for being slow and rigid. This one wasn’t. The key was treating each semester as a self-contained unit (Campaign) and making every rule configurable without code changes.

The Screen Flow approach for the application form turned out to be the right call. It gave us the conditional complexity the ministry needed (dozens of hide/show rules, cross-field validations, dynamic document requirements) while keeping everything maintainable through the Salesforce admin interface.

And the coordinator portal proved that you don’t always need a custom UI framework. With well-structured Community pages, custom CSS, and good tab organization, coordinators could manage hundreds of applications without training beyond a 30-minute walkthrough.