Part 1 of this series covered the ‘why’ of what a Salesforce portfolio is, why it matters more in 2026 than certifications alone, and what hiring managers are actually evaluating when they look at your work. If you skipped it, the short version is: build the portfolio.
This article is about the ‘what’. Specifically: Eight portfolio projects you can start today, split by track: four for Salesforce Admins, four for Salesforce Developers. Each one comes with a realistic business scenario, a concrete build list, an honest take on what it demonstrates to a recruiter, and a tip for presenting it in an interview.
You don’t need to build all eight. Two or three finished, well-documented projects will take you further than eight half-built ones. Pick the project that feels closest to the kind of work you want to do and start there.
Table of Contents
Salesforce Admin Portfolio Examples: 4 Projects Worth Building
A strong Salesforce admin portfolio doesn’t need to be massive. It needs to show that you understand what a business actually needs from Salesforce and that you can build it without overcomplicating things.
The four projects below cover the areas that consistently come up in admin hiring conversations: CRM data modeling, Flow automation, reporting and analytics, and process governance. They’re all buildable in a free Developer Edition org, which you can sign up for here.
One thing worth saying upfront: the scenario matters as much as the build. Don’t just build a Flow, build a Flow that solves a named problem for a named fictional business. That context is what separates a Salesforce admin portfolio that gets ignored from one that gets you a callback.
Portfolio Example 1: Lead-to-Close CRM for a Fictional Business
The Scenario: A small software startup is tracking its sales pipeline in spreadsheets. Deals get lost, follow-ups fall through, and nobody knows where a lead stands at any given moment. They’ve just set up Salesforce, and they need someone to build it out properly.
What to Build
- Custom fields on Lead, Contact, Account, and Opportunity that match what this specific business actually tracks, not just the Salesforce defaults
- Record types for different deal segments, if your scenario warrants it (residential vs. commercial, SMB vs. enterprise, product vs. services)
- A Lead conversion process that correctly links the new Contact, Account, and Opportunity, and maps the right fields across all three
- Opportunity stages that reflect a real sales process, with probability percentages that mean something
- Contact roles on Opportunities, because real deals involve more than one person
What it shows a recruiter: This is the Salesforce admin portfolio example that demonstrates end-to-end CRM thinking. When a hiring manager reviews it, they can see whether you understand how Salesforce objects relate to each other, not just individually, but as a system. That’s a meaningful distinction at the junior level.
Presentation tip: Record a three-minute Loom video walking through the org from a sales rep’s perspective. Start with the lead queue, convert a lead, update an opportunity stage, and finish with a quick pipeline report. Narrating it like you’re showing a new hire is more effective than a silent screen recording.
Portfolio Example 2: Automated Customer Onboarding Flow
The Scenario: Every time a deal closes, the customer success team manually sends a welcome email, creates a list of onboarding tasks, updates the account record, and sets a follow-up reminder for 30 days out. It takes about 45 minutes per customer, and things still get missed.
What to Build
- A record-triggered Flow that fires the moment an Opportunity reaches Closed Won
- An automated email alert to the new customer and the assigned Customer Success Manager
- Task creation for each onboarding milestone is assigned to the right person, with due dates
- Field updates on the related Account: status changed to Active Customer, onboarding start date populated
- A scheduled path inside the same Flow that creates a check-in task 30 days later
What it shows a recruiter: Flow automation is the most in-demand Salesforce admin skill in 2026. This project demonstrates it well, but more importantly, it demonstrates that you understand the business reason behind the automation. You’re not just building a flow because flows are impressive. You’re eliminating 45 minutes of manual work and removing the risk of things falling through the cracks.
Presentation tip: In your portfolio write-up, explain the decision you made about trigger type. Why a record-triggered Flow and not a scheduled Flow? Why task creation instead of just another email? These micro-decisions are what interviewers probe in technical discussions, and having clear answers prepared shows you thought it through.
Portfolio Example 3: Sales Performance Reporting Suite
The Scenario: A VP of Sales has three questions she asks every Monday morning: Where does the pipeline stand this quarter? Which reps are behind on quota? Where are deals getting stuck and sitting too long? Right now, she’s building this picture manually from three different spreadsheets.
What to Build
- A pipeline summary report grouped by Opportunity stage, filtered to the current quarter, not just a standard ‘All Opportunities’ view
- A rep performance report comparing closed revenue against individual quota targets by owner
- A sales velocity report showing average days spent in each pipeline stage. This is what makes stuck deals visible
- A dynamic dashboard that pulls all three together, with manager- and region-level filters
- A weekly email subscription so the VP receives the dashboard every Monday morning without having to log in
What it shows a recruiter: Most Salesforce Admins can build a report. Fewer can build a reporting suite that actually answers a business question. This project demonstrates the difference. You’re not showcasing features, you’re solving a specific problem a real VP has every Monday morning.
Presentation tip: Lead your portfolio entry with a one-paragraph ‘business brief.’ Three sentences: who the stakeholder is, what they need to know, and how often they need it. Then show how each component of the dashboard answers one of their questions. That framing makes the whole project easier to explain in an interview and makes it land better in writing.
Portfolio Example 4: Multi-Step Budget Approval Process
The Scenario: A mid-sized company processes budget requests via email chains. There’s no audit trail, approvals get lost, and nobody’s sure who has final authority on what. Requests under $5,000 need a manager’s sign-off; anything over $25,000 needs both the manager and a director. It needs to live in Salesforce.
What to Build
- A custom Budget Request object with the fields that matter: amount, category, business justification, department, and requestor
- A multi-step Approval Process with a conditional routing manager only for requests under $25k, manager plus director for anything above
- Email templates for each step: submission confirmation, approval notification, rejection with reason, and escalation alert
- Field locking once a request enters the approval queue, nothing should be editable while it’s in-flight.
- A dashboard view of pending approvals by stage and an average cycle-time metric
What it shows a recruiter: Approval processes are bread-and-butter Salesforce admin work in regulated environments, such as financial services, healthcare, legal, and government. Building one well demonstrates that you understand process governance, not just CRM configuration. It also signals you can work across departments, which matters to hiring managers who need admins to do more than manage the sales cloud.
Salesforce Developer Portfolio Examples: 4 Projects That Get Noticed
Building a Salesforce developer portfolio is a different exercise from building an admin one. The technical bar is higher, but so is the clarity around what matters: code quality, architectural judgment, and the ability to build things that work in production, not just in a sandbox.
When a hiring manager reviews a portfolio of a Salesforce developer, they’re not just checking whether the code runs. They’re asking: Does this candidate understand the governor’s limits? Are they thinking about bulkification? Do they know when not to write Apex? Do their test classes actually test anything?
The four projects below are designed to answer those questions clearly. Each one maps to a real skill area that consistently comes up in Salesforce developer hiring conversations.
Portfolio Example 1: Apex Trigger with a Clean Handler Pattern
The Scenario: The sales ops team wants an Account health score that updates automatically, calculated from the number of open opportunities, recent support cases, and last activity date. The scoring logic needs to run whenever any of those related records change, not just when someone edits the Account directly.
What to Build
- An Apex Trigger on the Account object, and this is important, with zero business logic inside it. The trigger body should be a single method call.
- A TriggerHandler class that holds all the actual logic, keeping it testable, readable, and maintainable
- Custom Metadata records to store the scoring thresholds so a business user can change the weights without requiring a new deployment
- A test class with 90%+ meaningful coverage: assertions that verify the actual scoring outputs, not just lines that were executed
- A README that explains the pattern, the business rule behind each score component, and how to adjust the thresholds
What it shows a recruiter: This is one of the best Salesforce developer portfolio examples for junior candidates, specifically because it addresses the most common junior developer mistake: logic-heavy trigger bodies that become unmaintainable the moment the requirements change. Showing that you know the TriggerHandler pattern and why it exists signals maturity that most entry-level candidates don’t demonstrate.
Presentation tip: In your README, explain why you chose Custom Metadata over hardcoded values for the thresholds. This specific decision shows production-environment thinking, the kind of thing a senior developer would ask about in a code review.
Portfolio Example 2: Custom Lightning Web Component (LWC)
The Scenario: A sales team works on retention-heavy accounts. Their standard Opportunity list view shows open deals, but gives no visibility into whether those same accounts have open support cases, which is often the earliest signal that a deal is at risk. They need both in one place.
What to Build
- An LWC that displays a rep’s open Opportunities and open Cases for the same accounts, side by side in a single view
- Wire adapters connected to Apex controllers to pull real-time data from the org, not hardcoded demo data
- Filtering and sorting controls are built into the component itself
- Toast notifications for in-component actions, like flagging an Opportunity as At Risk
- A README with a screenshot, a clear explanation of the business problem, and step-by-step deployment instructions
What it shows a recruiter: A Salesforce developer portfolio that only contains Apex is incomplete. Hiring managers at most companies need developers who can also build UI components, and LWC is now the standard. This project demonstrates frontend Salesforce development, component architecture, and the ability to solve a UX problem that declarative tools simply can’t handle. That’s a real differentiator for a junior developer role.
Presentation tip: Document the specific declarative limit you ran into that made the LWC necessary. Something like: ‘Standard list views don’t support cross-object filtering for related records, so a custom component was the right call here.’ That one sentence shows you evaluated alternatives before writing code, which is exactly what a senior developer would do.
Portfolio Example 3: External API Integration
The Scenario: When a new Account gets created in Salesforce, someone has to manually look up the company’s industry, employee count, and website to fill in the record. It takes five minutes per account and gets skipped constantly. The goal is to pull that data automatically from an external API the moment the Account is saved.
What to Build
- Named Credentials to handle external authentication; this is non-negotiable. Hardcoded API keys in Apex are an automatic red flag in any code review.
- An Apex HTTP callout class that queries the external API using the Account’s company name or domain as the search key
- A response parser that maps the API’s JSON fields to the correct Salesforce Account fields
- A scheduled Apex job that runs the enrichment nightly for any Account created in the past 24 hours
- Mock callout test classes using HttpCalloutMock. This is where most junior developers fall short, and where you can differentiate yourself clearly
What it shows a recruiter: Integration work is in almost every enterprise Salesforce job description, and it’s one of the skills that’s genuinely hard to fake in an interview. A Salesforce developer portfolio that includes a real integration project with Named Credentials, proper callout handling, and mocked test coverage tells a hiring manager that you’ve spent time on the parts of development that matter in production environments.
Presentation tip: Explain what happens when the API call fails. How does your class handle a timeout? What does the user see if the service is down? Error handling is one of the most revealing things about a developer’s production thinking, and it’s almost always absent from junior portfolios.
Portfolio Example 4: Agentforce / Einstein AI Prompt Builder Project
The Scenario: An SDR team is spending 20 minutes per prospect writing personalized outreach emails from scratch. Account info, Contact role, and recent activity all of it already lives in Salesforce. The goal is to build a tool that drafts the first email automatically from that existing data, so the rep reviews and sends rather than writing from scratch.
What to Build
- A Prompt Template that pulls Account industry, Contact job title, and recent activity data as dynamic merge fields
- A Flow that triggers the AI generation and presents the draft in a Screen Flow so the rep can review and edit before anything gets sent
- A lightweight feedback mechanism: a field on the Contact record where reps can mark whether the generated draft needs major edits or basic data for improving the prompt over time
What it shows a recruiter: This is the Salesforce developer portfolio example that marks you as someone paying attention to where the platform is actually going. Agentforce and Einstein Generative AI are the most active areas of Salesforce development in 2026. Candidates who have hands-on experience with Prompt Templates and AI-integrated Flows, even at a proof-of-concept level, are a small minority. That gap won’t last long, which is exactly why building this now puts you ahead.
Presentation tip: You don’t need a production-ready implementation. A working demo in a Developer Edition org with a clear README explaining the architecture, the prompt design choices you made, and what you’d improve next is more than enough to generate real interest from hiring managers who are themselves figuring out how to use these tools.
The One Rule That Makes All of This Work
Every project above will land differently depending on how well you document it. A lead-to-close CRM built with no explanation of the business scenario is just a configured org. The same build with a clear problem statement, documented design decisions, and a three-minute video walkthrough is a portfolio entry that gets you a second interview.
That’s the subject of Part 3. It covers how to write up your projects so they actually communicate your value, how to present your Salesforce portfolio in an interview without fumbling it, and the seven mistakes that quietly sink otherwise strong candidates.
Before you go there: pick one project from this article and spend an hour setting up your dev org today. The research, the reading, the planning, all of it is just procrastination until you’ve opened Salesforce Setup and started building.
Priya Rastogi
Priya is a Salesforce Admin who believes in the power of continuous learning and collaboration. She’s passionate about exploring how Salesforce can simplify work, boost productivity, and create better user experiences. When she’s not experimenting with new features or automating processes, Priya enjoys connecting with fellow Trailblazers and sharing insights to help others grow in their Salesforce journey.
Salesforce Trail Editorial Team
Salesforce Trail Editorial Team is a group of Salesforce professionals and content specialists dedicated to creating high-quality, practical, and easy-to-understand content for the Salesforce community. The team focuses on refining insights, ensuring clarity, and delivering value-driven content that helps professionals learn, grow, and stay ahead in the ecosystem.
- Salesforce Trail Editorial Team#molongui-disabled-link
