Salesforce Admins who want to stand out in the job market are often told to “build a few projects”, or words to that effect. But it’s sometimes hard to know exactly where to start. Trailhead badges are now table stakes, and hiring managers want to know how you think, not just what you can configure.
With automation accelerating and AI lowering the barrier to making things “work”, the idea of a good admin is shifting away from familiarity with features and towards decision-making, structure, and restraint. It’s not enough to be able to build something in Salesforce; you need to build it in such a way that reflects how a real enterprise actually operates in the real world.
So, let’s unpack what 5 meaningful self-serve projects actually look like in 2026, beyond generic portfolio-building, because, in a market shaped by AI, technical debt, and tighter hiring expectations, being able to demonstrate judgment – and having not just building skills but the mind of a good admin – matters more than ever now.
1. ‘Job Application Tracker’ App (Built Like a Real Project)
Nick Spencer, 12x Certified Salesforce Application Architect, spoke to SF Ben about what admins can do to make their resumes stand out. One suggestion, which Nick has been doing himself, is creating a fully self-contained Salesforce app that mirrors a real business use case. The idea behind it is to design and implement a solution end-to-end, including requirements, data model, automation, and rationale for design decisions.
Nick said: “I’ve created a job app. I’m tracking all of my applications and all my contacts in the Salesforce application as you expect to see.”
The project involves:
- Custom objects (like Job Applications, Employers, Recruiters).
- Relationships between contacts, companies, and applications.
- Status tracking and reporting.
- Optional automation for updates and reminders.
What makes it stand out is that the admin treats the project as a miniature consultancy engagement, even though they are the only stakeholder.
As Nick put it: “Effectively, you’re going to be doing this – every element of a project – just by yourself, and in miniature. So, you’re going to be your own business analyst. You’re going to be your own customer.”
He specifically mentions writing requirements, user stories, and acceptance criteria as part of the build process. “You’re going to be the person that’s coming up with the requirements, and you’re going to be the BA that’s then translating those requirements into user stories and acceptance criteria,” he said.
This demonstrates technical competence and solution design skills, again, importantly, showing now just what you can build, but being able to articulate the how and why.
2. End-to-End Solution With Standard Features First
Dave Massey, Founder of Get Force Certified and former Lead Solution Engineer at Salesforce, suggested that admins starting their careers should build a business end-to-end project, like a sales or service solution, which maximizes the use of standard, out-of-the-box features like assignment rules, web-to-lead, and email-to-case.
He emphasized that the project should demonstrate the business context and the value an admin can deliver, beyond the minimum ability to configure Salesforce.
Dave said:“If it were me and I was building them out myself, I’d probably pick one that is business end-to-end. So it’ll be something like a sales solution or a service solution, but something that’s actually going to capture as many standard features as possible, because that’s obviously best practice; you go with standard out-of-the-box features before moving on to anything custom.”
It’s important, Dave stresses, to maximize all of the “standard stuff” like assignment rules, auto-response rules, web-to-lead, email to case, etc. “You really want to make sure that when you’re building a project, you’re not just kind of being willy-nilly and creating custom stuff for the sake of it,” he said.
“You want to show that you understand those best practices. So I’d really focus on one which is end-to-end because that shows that you understand sales, you understand service, and you’ve got that business context.”
With projects like these, people sometimes focus too much on showing that they can configure Salesforce, but that isn’t always the best approach. “There’s just so much more to a project than that,” Dave says. “What you’re actually showing is the value that you can deliver, and that’s where, I think, it’s really important.”
To make this project stand out, the build should be tied to a fictional company with defined problems, so you can demonstrate why each configuration exists.
Dave said: “You want to give it a bit of context. So that way you’re not just saying, ‘Oh, I configured duplicate rules.’ You’re saying, ‘Well, this was what I saw as the solution to this problem.'”
From a technical perspective, this shows mastery of core Salesforce setup, object relationships, automation boundaries, and feature selection, all within a single end-to-end solution.
3. Data Access, Security, and Sharing Architecture Project
Salesforce’s security model provides a good opportunity to show off your skills, building something around a realistic multi-role organization. The goal here is to demonstrate deep understanding of who can see what, who can do what, and, perhaps most importantly, the why behind all of it.
Dave describes this as critical, telling SF Ben: “I’d look at a project for data access and security because again, that’s, in my opinion, the most important part of Salesforce – understanding what people should see, what they should be able to do, what they shouldn’t be able to do.”
Technically, this project should include:
- Multiple user personas (e.g., sales users, sales managers, service users, service managers).
- Org-wide defaults.
- Roles and role hierarchy.
- Profiles, permission sets, and permission set groups.
- Sharing rules, manual sharing, and team sharing.
The strength of this project is that it demonstrates intentional security design, not just ticking configuration boxes.
Dave said: “That way you’re working with the core objects. And then you look at how you have profiles, you have permission sets, you go to permission set groups, you configure org-wide defaults, you have roles, and the hierarchy… You get sharing rules in there. You have a use case for manual sharing and team sharing.”
He added: “What you’re actually showing them is, ‘Hey, I know Salesforce. I know what we should do with it. I know how we should configure it.’”
This project immediately separates admins who understand Salesforce’s data model from those who don’t. A useful way to stand out!
4. Flow-Focused Automation Project
Career-focused admins could also consider a dedicated automation portfolio, centered entirely on Salesforce Flow, but built with restraint, documentation, and architectural awareness.
“I’d just have a project with loads of different Flows in there,” Dave says. “And I’d probably look at maybe three to five, because you want three to five really solid ones.”
This should include Record-Triggered Flows, Screen Flows, and Autolaunched Flows, each with a clear use case and justification for why that Flow type was chosen.
This is not just about building flows inside Salesforce. Dave stresses the importance of mapping and documenting Flow logic: “You’d have the documentation. You’d have the lucid chart where you’ve mapped it out, and you’ve made notes to say this could impact this, this could impact that.”
The project should also demonstrate Flow best practices, like avoiding DML in loops and including proper error handling – details Dave explicitly calls out when discussing red flags. Ultimately, the technical value of this project is not volume, but intent.
Dave says: “Projects are not about showing you can do something. They’re about showing that you understand why you should or shouldn’t do something.”
A well-executed Flow project like this proves not just automation skill, but architectural judgement – something hiring managers immediately notice.
Nick also emphasized Flow as an arena where Salesforce Admins can clearly show a real technical skill or expose weaknesses. Creating well-designed, production-ready Flows is certainly a valuable skill, along with, again, explaining why they were built that way. Are you seeing a pattern here yet?
This project should show the following:
- Record-triggered flows using the correct object.
- Proper use of before-save (fast field update) flows.
- Clear entry criteria.
- Fault paths and error handling.
- Avoidance of unnecessary related-record updates.
Nick said: “Flow is the one area where you can make a mess and it will still work. That’s quite often the problem: You can make it messy, and it will work, but it won’t work at scale.”
It doesn’t need to be perfect, but you must be able to defend the thinking behind why you made certain decisions. “It might well not be perfect… as long as you can explain why it’s not perfect, and why you haven’t gone through making it perfect, that’s absolutely fine,” Nick said.
5. Something ‘Out-of-the-Ordinary’ or Experimental
A key bit of advice that Nick shared with us is to build something unusual, but contained. Something that signals curiosity and technical initiative, even if it’s not production-ready.
He gave the example of integrating ChatGPT into Salesforce. He stresses that he’s not necessarily advocating real-world use for that integration, but doing something “a little out of the ordinary” can be worthwhile.
This project could include:
- Authentication handling
- A basic UI surface (like a button, Flow, or utility bar)
- Prompt construction and response handling
He adds that this works as a non-production demo. “It’s fine as a little testing thing in the background, but it also shows an element of thinking outside that darn box.”
Showing where Salesforce ends, and code begins – along with where external services fit in – is valuable, even if it’s not necessarily enterprise-ready, and without over-engineering things.
Nick told SF Ben: “It’s not necessarily the final product, whether it looks particularly shiny or not, but it’s if you can show how you got there, the decisions you took when building this.”
Final Thoughts
Both Dave and Nick are pointing admins in the direction of self-serve projects, which matter because they take into account how Salesforce is actually used in the real world. Simply stacking features, copying Trailhead builds, or proving you can click the right buttons, isn’t really enough to make your Salesforce Admin resume jump out.
The best projects are end-to-end, grounded in a realistic business scenario, and purposefully designed around standard Salesforce capabilities, before anything custom. The common thread between the above projects is intentionality – they work because they demonstrate how the admin considers and understands context, trade-offs, and best practices.
That is to say, why features exist, along with when to use them – and, just as crucially, when not to use them.
