The quick version: one project built properly and written up honestly beats five half-finished ones. The write-up is what does the work, because anyone can produce screenshots of an org and almost nobody explains the decisions. Explaining a decision, including one you got wrong, is the thing that distinguishes a portfolio from a gallery.
What to build
Find a requirement that exists. A charity, a club, a small business, a process in your current job. The requirement being real is what makes the project useful, because real requirements contain the awkward parts: an exception that breaks the clean model, a person who needs different access, data that arrives in the wrong shape.
Invented requirements are always tidy, and a tidy project demonstrates nothing.
Scope it to something finishable in two or three weekends. A finished small thing is worth more than an ambitious unfinished one, and unfinished is what most portfolio projects are.
What to put in it
Enough to show a range without padding:
- A data model with at least one relationship where you chose between lookup and master-detail, and can say why.
- Automation that does something a person would otherwise do by hand. One flow that solves a real annoyance beats four that demonstrate features.
- A validation rule or two that prevent mistakes someone would actually make.
- Permissions for at least two different kinds of user, with different access. This is the part people skip and the part that shows you understand the platform’s security model.
- A report or dashboard answering a question the requirement actually poses.
- Some Apex, if you are going the developer route, with tests that assert something.
The write-up is the portfolio
For each significant decision, three sentences: what you chose, what else you considered, why you chose it. That is the entire format and it is more persuasive than any amount of screenshots.
Include the things you got wrong. “I built this as a lookup, then discovered I needed a roll-up, and converting was harder than expected because of the null records” is the single most credible paragraph you can write. It tells a reader you have hit reality. A portfolio where everything went smoothly reads as either trivial or untrue.
Where to put it
A public repository with the metadata and a README, and a short write-up somewhere readable. The repository matters more than it seems: it shows you can use source control, which a surprising proportion of Salesforce people cannot, and it lets someone technical see the actual work rather than a description of it.
sf project retrieve start against your Developer Edition org, commit the result, write the README. That is the whole workflow, and doing it demonstrates the DevOps basics alongside the build.
What does not help
- Trailhead badge counts. They show completion, not judgement. Everybody has them.
- Screenshots with no explanation. A picture of a flow proves you opened Flow Builder.
- Five unfinished projects. Reads as an inability to finish, which is the opposite of the message.
- Anything from a paid course, unmodified. Interviewers recognise these, and a project thousands of people have built is not evidence about you.
Use it in the interview
Bring it up before you are asked. “Can I show you something I built” changes the shape of an interview from being assessed to explaining your work, which is a much better position and a more accurate picture of how you would actually be.
Have one difficult decision ready to talk about in detail, and one mistake. Both will come up, and having thought about them beforehand is the difference between a good answer and a scramble.
Keep it alive
An org built two years ago and untouched is a museum piece, and the release notes have moved on. Revisit it when something relevant changes, add the new capability, and write a paragraph about what you changed. That turns the portfolio into evidence that you keep up, which is a separate and valuable signal.
Frequently asked
Can I use my current employer’s work? No, and being asked and declining is itself a good signal. Build something separate.
Does the org need to stay live? Developer Edition orgs expire if unused. Keep the metadata in the repository and the write-up independent of the org, so neither depends on it.
How long should the write-up be? A page or two. Long enough for the decisions, short enough that someone reads it before your interview rather than during.
