The Experience Cloud portal I wish recruitment systems actually had
When people talk about recruitment platforms, they usually focus on the ATS.
Jobs. Candidates. Pipelines. Reports.
But after rebuilding our entire stack directly on Salesforce, I’ve come to a different conclusion:
The portal is the product.
Everything else is plumbing.
Candidates, locums, and clients don’t experience your ATS.
They experience whatever you put in front of them.
And in most recruitment systems, that experience is… not great.
Portals are usually an afterthought
Most ATS vendors treat portals as a bolt-on:
expose a few internal objects
apply some permissions
add a logo
call it “self-service”
Technically, it works.
In practice, it fails quietly:
users get confused
adoption stays low
internal teams pick up the slack
emails and PDFs reappear “just in case”
The portal exists, but nobody trusts it.
When I started building directly on Salesforce, I decided to flip the thinking:
What if the portal wasn’t a cut-down version of the internal system — but its own product surface?
External users don’t want flexibility — they want certainty
One of the biggest mistakes I see in Experience Cloud builds is assuming external users want choice.
They don’t.
Locums don’t want to “manage records”.
Practices don’t want dashboards.
They don’t care about Salesforce objects, fields, or layouts.
They want:
to submit a timesheet
to approve something
to upload a document
to know what happens next
Anything beyond that is noise.
So we made some deliberate decisions that go against “classic Salesforce thinking”:
fewer editable fields
fewer navigation options
fewer decisions for users to make
strong status-driven flows
lots of things that are simply not allowed
Not hidden.
Not discouraged.
Impossible.
The result was counterintuitive but powerful: adoption went up when flexibility went down.
A good portal hides Salesforce
This became a guiding principle:
A good Experience Cloud site hides Salesforce.
A bad one exposes it.
That meant:
avoiding record pages wherever possible
preferring screen flows over forms
using repeaters instead of data tables (especially on mobile)
designing task-based screens, not object-based ones
removing anything that required explanation
If a user needs instructions, the design has already failed.
Mobile-first isn’t optional (even if Salesforce makes it awkward)
Most locums submit timesheets on their phones.
Most approvals happen between consults or meetings.
Almost none of this happens at a desk.
Experience Cloud can work well on mobile — but only if you design for it deliberately.
That meant:
testing everything on a phone, not just resizing a browser
avoiding dense layouts
limiting scrolling
killing anything fiddly or precise
accepting that some Salesforce components just aren’t suitable
Repeaters beat tables.
Big buttons beat clever UI.
Whitespace beats information density.
Not because users are unsophisticated — but because they’re busy.
Self-service only works if the system leads
One rule I set early on:
If a process relies on people remembering what to do, it isn’t automated.
So the portal doesn’t explain workflows.
It enforces them.
Examples:
users can’t submit incomplete timesheets
approved records lock automatically
rejected items come back with a single, clear next step
reminders are automatic
statuses drive what’s visible and editable
The system carries the process — not the person.
That single shift removed a huge amount of internal admin and back-and-forth.
Security and licensing forced better design
One of the more unexpected constraints was licensing.
Salesforce Enterprise orgs include 20,000 free External App logins — but Experience Cloud customer licences cost money, and lots of them.
Instead of defaulting to paid licences, I treated this as a design problem:
What actually needs to be exposed?
What should never be visible externally?
Where can flows replace direct object access?
How do we keep data isolated without relying on trust?
With careful architecture, strong permissioning, and a flow-first mindset, we built a secure portal using free licences — without compromising privacy or control.
That constraint forced cleaner boundaries between internal and external systems — which made everything better.
The portal changed how we think about internal processes
This was the unexpected upside.
Once you’re forced to present a clean, simple experience externally, you can’t hide internal mess anymore.
Broken processes surface immediately.
Inconsistencies become obvious.
Edge cases demand answers.
Building the Experience Cloud portal didn’t just improve the user experience — it exposed where our internal workflows needed tightening.
In that sense, the portal became a mirror.
What I’d do differently
A few hard-earned lessons:
Don’t expose internal objects just because you can
Design for one task per screen
Decide early what should be impossible
Assume zero training
Treat licensing as an architectural constraint, not an afterthought
Build for the real world, not demos
The bigger takeaway
Experience Cloud isn’t “just a portal”.
Used properly, it’s where:
trust is built
admin disappears
adoption either happens… or doesn’t
Most recruitment platforms get this wrong because they start from the system and work outward.
We did the opposite.
We started with how people actually behave — and forced the platform to meet them there.
That decision changed far more than the UI.
