Customizing Salesforce in Higher Ed: A #HigherEdLoveStory

By: Jace Bryan, Higher Education Advisory Council Member, Texas A&M University-Commerce @JaceBryan_

This is the first blog in a series of Salesforce Higher Education Advisory Council Blogs surrounding the Build vs. Buy discussion.

If your Salesforce CRM story is the same as mine then you are in for a real treat. If not, no big deal! You will still learn how one Higher Ed Admin (along with his trusty IT side-kick) customized Salesforce without the need for an implementation partner, vendor partner or managed package solution. So sit back, relax, and be prepared to be amazed! There are indeed many #SalesforceHigherEdLoveStories in the world of CRM and today I have the pleasure of telling you mine.

For those new to Salesforce (or those already using the Salesforce ecosystem) I would like to take a moment to introduce you to the Salesforce.org Higher Education Advisory Council (HEAC).

The Higher Education Advisory Council collaborates with Salesforce and industry partners to make Salesforce work for Higher Ed. They fulfill this mission by:

• Leveraging our collective higher ed, IT, and Salesforce expertise to make a difference on our campuses
• Maintaining a collaborative community that shares code, best practices, and documentation
• Identifying needs and advocating for solutions
• Connecting with new and prospective Salesforce Foundation higher ed customers
• Participating in outreach efforts through webinars, blogs, Higher Ed Summit presentations, Force For Change Grant applications, etc.
• Recognizing the diversity of functionalities and needs of higher ed institutions

The Higher Education Advisory Council recently divided into subcommittees to focus on important and relevant topics impacting the world of Higher Education in Salesforce. This blog was created by the Lead of one of those subcommittees, the Build vs. Buy sub-committee, whose goal is to bring important, relevant and helpful information to the surface in the context of making a decision in the build vs. buy dialogue. I am the Lead of the Build vs. Buy subcommittee and this is my story.

Assumptions

I am making the following assumptions about those reading this blog:

1. You are in Higher Ed looking for a CRM solution; OR
2. You are in Higher Ed using Salesforce and are looking for ways to customize it without the need for an implementation partner, vendor partner or managed package; AND/OR
3. You are interested in the Build vs. Buy discussion and want to know more about it.

What is the Build vs. Buy discussion?

“To build or to buy – that is the question.” – Me~

All Universities will eventually face this question. In my experience I’ve seen it happen in 3 ways:

1. When a University has selected Salesforce as their CRM of choice and are trying to identify if they should go with native Salesforce functionality based on their business needs;
2. When a University is already using Salesforce and are looking to add additional functionality but have no internal resources to address the need; or
3. When a University is already using Salesforce and is looking for a total packaged solution that resembles pieces to the Student Lifecycle (i.e. Recruitment, Retention, Advancement, etc…)

To Build (in a nutshell)

To go with a “Build” solution is to customize Salesforce to match your organization’s business processes. In the build scenario, you scope a solution (with or without an implementation partner) and focus on building out your needs piece by piece until the whole picture comes into view.

To Buy (in a nutshell)

To go with a “Buy solution” is to identify that there are “ways” of doing “things” in Salesforce that are not part of native functionality AND rather than building out individual pieces to a Student Lifecycle puzzle you would rather adjust your business processes to match Salesforce’s native functionality, or you utilize a pre-built customization (an application) that covers the student lifecycle gamut. Rather than focus on building out your needs piece by piece, you go with a total solution that includes all (or many) of the pieces.

What about an implementation partner? Are they part of the Build vs. Buy discussion?

It depends. If you’re planning to use Salesforce “out of the box”, or if you’re planning to utilize internal resources at your University to build out Salesforce for your team, then no. However, if you plan to use an app (a “buy” solution) or if you plan to customize Salesforce to match your business processes and you do not have an internal resource who gathers those requirements and implements them into your Salesforce org (a “build” solution), then yes.

My Story

When Salesforce was selected for use by our Graduate Recruiters we had very little implementation knowledge to go off of. We didn’t have a dedicated resource “team” to accomplish the still unknown business needs and goals and further, we didn’t have internal Salesforce knowledge to keep the fires stoked and to keep the business users excited about a very powerful solution to their existing dilemma – Spreadsheets. When we started with the 10 free Power of Us subscriptions we were excited about the term “free”. It helped coin the phrase I use often, “Try before you buy.” Having access to 10 free subscriptions allowed us to start with a prototype (phase 1) to move our users into Salesforce by duplicating their existing spreadsheet fields in Salesforce, and to get them setup with email templates and reporting.

Phase 1 took a long time to complete. Business user requirements gathering and training were the biggest obstacles. (Keep in mind Phase 1 was before the awesomeness of Trailhead!) After Phase 1 was complete, I decided it was necessary for my University to have a dedicated Salesforce Admin, so I volunteered to lead that initiative. A few months later, with Salesforce Admin and Advanced Admin training behind me, and my Admin Certification in my back pocket, I felt better prepared to launch into phase 2: integration with our SIS. As a Certified Salesforce Admin, I was better prepared to help users understand the native functionality of Salesforce, explain known limitations (i.e. Mass Emails, Workflow Limits, etc.), and identify methods for training my end users – including creating documents, YouTube videos specific to our configuration, as well as creating a Case Management Portal for use with Change Requests supported by Approval Processes. I also spent a lot of time understanding the SIS integration using a cloud ETL tool which moved student data from our SIS into Salesforce. The hidden benefit of using the ETL tool: there were many issues with data in the SIS and now they were visible, not only to me, but to my teammates as well.

During our initial phases, it was imperative that I learn as much as possible about native Salesforce functionality and provide options in native Salesforce to my users to support their business process, reporting, and communication needs. I spent hours in a development org taking their needs and turning them into viable solutions that I would then demo to my end users. If they agreed it was a YES, I would schedule training, plan a deployment, create documentation and then set a go-live date. However, if my solution was not greenlighted by my users, I would go back to the drawing board and start over again. With so many ways of doing things within Salesforce (good, better, best), my plan was to push Salesforce to the limits.

Creating custom fields, custom report types, email templates, and workflows were easy to do once I had the proper training. Understanding native Salesforce functionality came with not only attending Salesforce Admin training AND getting certified, it also came with a passion to make the Salesforce experience as awesome for my users as I knew it could be. It meant time spent going through all the known documentation Salesforce provides, along with customer success stories found in the Power of US Hub and Success Communities. It meant reaching out and connecting with others like me who had all these questions and yet didn’t want to waste time reinventing the wheel. (Especially if another University had a solution I could use!)

After a few years of using Salesforce, which included several user meetings, business process discussions, end-user training sessions, Salesforce Higher Ed Summit and Dreamforce presentations, and executive leadership buy in presentations, we were ready to move the Build vs. Buy discussion forward. After all, how can you even identify what to build or buy, when you are still trying to figure out what your needs are? Please note that we have not ironed all the kinks that come with a solid CRM implementation. We are still trying to figure out (and hopefully we achieve this soon!) how best to create a CRM roadmap along with vision and strategy, timelines and governance. But that is for another blog!

Stay tuned for the next blog in the Build vs. Buy series that will focus on Build vs. Buy considerations and how those considerations can (and probably will!) impact your implementation!