Why I Built a Job Board Inside Salesforce

I didn't originally set out to build a software company.

I run a recruitment business, and for years we had the same problem that a lot of businesses using Salesforce have: Salesforce contained our jobs, candidates, applications and recruitment data, but our website sat outside of it.

That never made much sense to me.

Every time we wanted to change something on our job board, improve the candidate experience or introduce a new feature, we were dealing with the boundary between Salesforce and the website.

So I started building.

The first version was just for us

The original objective was straightforward.

I wanted our jobs in Salesforce to appear properly on our website, and I wanted candidates to be able to interact with those jobs without us maintaining a separate database or constantly moving information between systems.

Salesforce should remain the source of truth.

A recruiter creates or updates a job in Salesforce and the website reflects it. A candidate applies and the information comes directly back into Salesforce.

No synchronisation layer. No duplicate job database. No separate recruitment platform sitting between Salesforce and the website.

Over time, what started as a solution to our own problem became considerably more sophisticated.

We built job search and filtering, job detail pages, applications, candidate portals, timesheets, compliance and other functionality around it.

And because I was using the system every day in an actual recruitment company, I kept finding things I wanted to improve.

Then I realised we'd built it the wrong way

Not technically wrong.

Commercially wrong.

Our original system was built specifically for Recruit4Vets.

Our objects. Our fields. Our processes. Our terminology.

That was fine when we were the only company that would ever use it.

But I started asking a different question:

Why couldn't another Salesforce customer use this?

That changed the architecture completely.

Instead of building another Recruit4Vets job board, I started rebuilding it as a framework.

The important difference is that the new system doesn't need to know how we use Salesforce.

It needs to understand how your organisation uses Salesforce.

The job board shouldn't dictate your Salesforce architecture

This became one of the core principles behind what I'm now building at OndaWorx.

A software package shouldn't arrive in your Salesforce org and tell you that your jobs must be stored in a particular object, that the job title must be in a particular field or that your organisation has to adopt somebody else's data model.

The framework should adapt to the organisation.

So the new OndaWorx Job Board is being built around metadata.

An organisation can define which Salesforce object represents a job, which fields should appear, how jobs should be filtered and sorted, and how different pages should behave.

The underlying engine remains the same.

The configuration changes.

That might sound like a relatively small technical distinction, but I think it changes what the product can become.

This isn't just for recruitment agencies

This was another assumption I had to reconsider.

I initially thought the obvious market was recruitment companies using Salesforce.

It certainly is one market.

But almost every organisation recruits people.

A company running its business on Salesforce may have hundreds or thousands of employees and still send candidates away to a completely separate platform when they visit its careers page.

Why?

If the vacancies already exist in Salesforce — or the company wants Salesforce to become the recruitment system of record — there is no fundamental reason the careers site can't be driven directly from Salesforce as well.

That means the same underlying engine could power a recruitment agency's public job board, an employer's careers website or potentially an internal jobs marketplace.

The presentation and configuration can be completely different.

The engine doesn't have to be.

Why Salesforce-native matters

There are plenty of job board products already available.

I'm not trying to build another generic hosted job board and connect it to Salesforce with an API.

The premise is different:

Salesforce is the platform.

The job board is an extension of it.

That means the data, security model, automation and business logic can remain within the Salesforce environment rather than being replicated into another application.

For organisations that have already invested heavily in Salesforce, I think that's an important distinction.

And it leads to a broader idea I've become increasingly interested in.

Salesforce doesn't necessarily need another enormous application that attempts to replace an organisation's entire operating model.

There may be a much more interesting opportunity in building highly focused engines that solve individual problems exceptionally well and work together on top of the Salesforce platform.

The job board is the first of those for OndaWorx.

Building it as a product changes everything

Building software for your own company and building software that can be installed into hundreds of completely unrelated Salesforce organisations are very different things.

I've had to rethink decisions that previously seemed trivial.

What happens if the customer uses completely different objects?

What happens if a field doesn't exist?

What happens when the package is upgraded?

What should be configurable and what should remain controlled by the application?

How do you prevent one customer's configuration from affecting the underlying product?

How do you make something flexible without making it impossibly complicated to configure?

Those questions have probably been the most interesting part of the project.

The objective is no longer simply to make something that works.

It has to be something that can work anywhere.

Where this is heading

The job board is now being developed as a Salesforce managed package with the intention of making it available through AppExchange.

There's still work to do before I consider it finished.

But for the first time, I'm not building software purely to solve a problem inside my own recruitment company.

I'm building something because I think other Salesforce customers have the same problem.

And that is ultimately what OndaWorx is about.

Find the parts of a business that shouldn't require another disconnected software platform.

Build them natively on Salesforce.

Make them configurable enough to work for organisations we've never met.

Then let Salesforce remain what it is exceptionally good at being:

the platform underneath the business.