Simple Method to Identify Blank Fields in Visualforce

I've often wondered why there is no ISBLANK() equivalent in Apex for developers to use when validating a Visualforce page. Maybe Salesforce always intended for developers to use the required attribute for the standard Visualforce components.

The problem with relying on field settings, Visualforce required attributes or object validation rules is that there is no consistent presentation of the error messages. For different sites, especially public ones, sometimes the validation errors need to be tailored specifically for the site.

To help this process along, I modularized the concept of ISBLANK() in the simple instance method below.

/**
 * Determine whether a given object is blank
 * or not, in the same manner as the ISBLANK()
 * Visualforce function.
 *
 * @param  o The object to examine
 * @return   Whether the object is blank
 */
public Boolean isBlank(Object o) {
    return o == null;
}   // public Boolean isBlank(Object o)

With this simple method (or variations thereof), developers can iterate through a List<Schema.SObjectField> of required fields and use controller.isBlank(Object) to validate the fields.

for (Schema.SObjectField field : requiredFields) {

    if (isBlank(application.get(field))) {
        addRequiredFieldError(field);
        isValid = false;
    }   // if (isBlank(application.get(field)))
    
}   // for each Schema.SObjectField in requiredFields

What is an enrollment product in higher education?

When it comes to enrollment management, I hypothesize that institutions in the education industry share many common administrative concerns as companies in other industries.

1. What's our forecast for the next quarter or year?
2. How much are we allocating to Marketing?
3. What's our historical ROI on past campaigns? And what are we expecting for new Marketing campaigns this year?

But one big difference I see between education institutions and other companies is how the above questions are answered. While other companies usually answer Questions 1 and 3 above with dollar amounts, education institutions (from the enrollment perspective) answer with student headcount or with class enrollments.

This may seem like a trivial distinction, but how useful would it be for Apple to announce their forecasts using the numbers of iPhones, iPads and MacBooks it plans to sell in the next year? Or worse yet, what if Apple simply said it would sell 1,000,000 products this year? And how would Apple's Marketing department calculate ROI for its myriad campaigns if this was the case?

Back in the world of education, I think there is a mental roadblock which prevents us from recognizing what our products truly are. Culturally, we, the administrators, think highly of education (which we should). But perhaps we've become ignorant of the underlying business model for education, which in the simplest sense revolves around the sale of products to customers. Put another way, the business model revolves around the enrollment of students in classes.

Let's explore the potential similarities and see whether they are legitimate.

• Student vs. Customer
• Enrollment vs. Sale
• Course vs. Product
• Class vs. Lot
• Seat in a class vs. Asset

We have recruiters, enrollment coaches and advisers who work with students to identify which courses to take to best meet their career aspirations and personal goals. Once the courses are identified, our staff help students to register for classes, thereby reserving their seats in the upcoming term. Once the add/drop period ends for a term, the enrollments are "closed" and invoices are sent to the students.

Other companies have salespeople working with customers to pick the most suitable products for each customer. Once customers decide to buy, they put in orders that are fulfilled in lots, resulting in assets (and associated invoices) delivered to each individual customer.

So, how different is an education institution from other companies? And if it's not that different, could adoption (or at least reconciliation) of real sales terminology be the way for an education institution to start answering the tough questions directly with real dollar amounts?

Note: I speak largely from my own experiences, and I recognize that there are other institutions which are already far along on the path of leveraging the concept of products in their CRM operations.

What is a program in higher education?

As system maintenance becomes more difficult, and as user dissatisfaction with reporting grows, I've been thinking a lot about one of the most controversial 4-word questions in higher education: "What is a program?"

I still remember some of the answers from when I first asked the question on Chatter last October.

• "I would define a program as a sequence of college level courses (credit bearing) that lead a student to a certificate, degree, or diploma."
• "I think specializations would be subcategories or tags within programs. I don't see Fast-Track degrees as separate programs. To me, that is similar to online vs. on-campus delivery. Same program, different delivery methods."
• "I think what makes one program different from another is its required content. FT requires a certain and specific content (in a specific order even), so I would categorize it as a different program. However, online v on-ground wouldn't be a different program. Specializations have specific required content, so even though they don't end in different degrees, I would probably classify them as different programs."

Unfortunately, we never reached a conclusive answer. And the systems architect in me wanted a firm definition of a "program" in higher education so that I could help to design a system that best fit our business processes. Argh! "Frustrated" only begins to describe how I felt at the time.

But now, I have a different take on the question, with much less frustration.

For starters, let me back up and say something about our industry. I think the notion that higher education is somehow inherently different from all of the other industries out there has made me blind to the broader definition of the word "program". People in higher education can elevate and romanticize the industry to the point where colleagues will frown upon the application of business terminology (like "programs") to our operations. By removing the higher education context from the word, I feel like my grasp of "programs" has improved by leaps and bounds.

Let's jump back start with a program in higher education and see if we can discern any important characteristics.

All programs in higher education seem to have the following:

• Eligibility criteria: Who is eligible to be considered for entry into the program? For example, to be eligible for a master's degree program, an individual should currently hold a bachelor's degree.
• Entry procedure: If eligible, how does a person enter the program? Usually, a person enters a program by submitting an application for admission and then being accepted after a formal review of that application.
• Curriculum: Once in the program, what courses is a student expected to take?
• Services and perks: While in the program, what services or perks can a student expect to receive or have access to?
• Maintaining program membership: What does a student have to do to remain in a program? For example, if a student does not complete a program within 7 years then that student is effectively out of the program and must apply again for re-entry.
• Completion criteria: What does a student have to do to complete the program? Usually this involves passing all of the courses in a prescribed curriculum.
• Reward for program completion: What does a student get for completing a program and graduating? In higher education, a graduate typically receives a combination of degree, major, minor, concentration and specialization from the institution to attest that the graduate now holds certain level of skill and knowledge within a field of expertise.

What's so special about this notion of a program is that this concept is not rigidly constrained by the generic, systematic definition (to which there are currently many exceptions) at our institution that programs are defined by distinct combinations of degree, major, and concentration.

And the real value of this discussion may be simply acknowledging that creating, changing, splitting, merging and retiring programs are more parts of an art than a science, which is how I imagine programs are treated in other industries like retail and fitness.

To give this concept a test drive: How may the different notions of a "program" play out in the following two scenarios?

Scenario 1: Doctoral program with specializations

Historically, we have had a doctoral program with specializations that was only ever tracked as a single program record in our student information system. However, Marketing would typically promote the handful of specializations as if they were separate programs on our website, because the target audiences were different enough and the rewards were different enough (in the eyes of our students).

In our CRM system (Salesforce), should the program records match 1-for-1 those in our student information system?

Scenario 2: Doctoral program with varying requirements

We also have a doctoral program that has slightly different curricula for students entering with a bachelor's degree compared to students entering with a master's degree. Historically and in the near future, the plan would still be to market this program as a single program on our website. But on the back end, the registrar's office created two separate programs in our student information system in order to better track our applicants and students.

Again, in our CRM system, should the program records match 1-for-1 those in our student information system?

NO-SOFTWARE Salesforce Tutorial: Internal Web Service Callouts

Another developer recently talked about a situation where an Apex web service needed to be exposed to internal, authenticated users in order to work around a DML limitation.

The concept behind the workaround was very intriguing, and after playing around with some Apex code I came up with a tutorial that I hope others may find useful: NO-SOFTWARE Salesforce Tutorial: Internal Web Service Callouts

The key concepts demonstrated in the tutorial include:

• Generating a WSDL from a global Apex class
• Generating Apex from a WSDL created from a global Apex class
• Using the UserInfo.getSessionId method to make callouts to internal web services as an authenticated user