The Salesforce developer who is trusted to choose

🆕 New & Trending AI Tools for Salesforce DeveloperReviewed September 2026

We track new AI-tool launches every week and refresh this list — here’s what’s gaining traction for Salesforce Developer work right now.

The discount the org has never stored

A sales manager wants the opportunity page to show a discount the org has never stored. Reps would type a promised cut in a note today and hope finance agrees later. A Salesforce developer opens the opportunity object, the price fields that already exist, and the Lightning page the reps actually use on a call. The honest build is a field with a clear meaning, an Apex path that calculates the discount from rules finance will sign, and a Lightning component that shows the result without letting a rep save a number the org cannot explain. The developer sketches that in a sandbox, walks finance through a sample opportunity, and refuses to hide the math in a free-text box. The org, not a slide, is the product.

Salesforce developers write Apex, build Lightning experience pages and components, and change the org the business runs on. They sit with administrators, with the sales or service leader who owns the process, and with an integration owner when another system must see the same opportunity. The day is a sandbox, a set of objects and fields, a trigger or a service class, a Lightning page, and a deployment toward production. The decision is whether the platform's configuration already does the job, or whether Apex is justified because the rule is too specific to click together. Shipping means the production org behaves the way the sandbox did for the records reps will touch tomorrow.

You work inside one company's org or across customer orgs if you are at a partner. The users are reps, agents, managers, and sometimes customers on an experience page. Their words are pipeline, case, discount, approval. You translate those words into objects, automation, and screens, and you keep a dictionary so "discount" does not mean three different fields by winter. Production habits are sandbox discipline, tests that run with the deployment, and a change that an administrator can recognize after you have moved on.

Apex, Lightning, and the org reps live in

Apex earns its place when a rule must be enforced no matter which screen saved the record. A trigger or a domain class checks the discount against the finance rule, writes a reason when it blocks the save, and stays bulk-safe so a data load does not fall over. You keep queries selective, you avoid work that explodes as rows grow, and you put the business rule in one class the next developer can find. Tests cover the allowed discount, the rejected one, and a bulk update. Anonymous scripts in production are a smell. The same logic belongs in the deployment, with tests the org will run before the change is trusted.

Lightning is what the rep sees. A record page should surface the discount, the reason, and the next action without a scavenger hunt through related lists that do not match the talk track. A Lightning web component fits when the page must calculate or guide in a way the standard layout cannot. You still prefer standard and dynamic forms when they tell the truth, because every custom component is a surface you must maintain through platform releases. You sit with a rep and watch them update an opportunity. Where they hesitate, the page is wrong, even if the Apex is elegant. Accessibility of the page matters here too: labels, keyboard use, and a message a person can understand when the save is refused.

The org is the long-lived system. Sandboxes refresh and drift. Production holds the profiles, permission sets, flows, and integrations that make a field visible to the right people and hidden from others. You deploy with the path the company trusts, whether that is a deployment pipeline or a careful change set, and you know how to back the change out. You watch governor behavior by writing Apex that stays calm under bulk, without treating limits as trivia to recite. You document the object model in the words finance and sales already use. An org stays healthy when custom Apex shrinks to the rules configuration cannot hold, and when those rules are tested every time they move.

Credentials Salesforce grants

Salesforce grants its own credentials. Platform Developer credentials speak to Apex, Lightning, and the platform features a developer touches. Administrator credentials are common beside them, because a developer who cannot see how profiles and objects fit will fight the org. The vendor is the granting body. Employers, especially partners and teams that live in a large org, often expect at least one of these credentials as a sign you have studied the platform's terms. The credential shows preparation. It does not show that you have shipped a discount rule finance will sign.

Prepare with a developer edition org or a sandbox you are allowed to break. Build an object, an Apex rule with tests, and a Lightning page a colleague can click. Take the vendor's training as study, and skip any story about how an exam is assembled or scored. In the hiring conversation, offer to narrate the sample opportunity from the button the rep presses to the field the report reads. If a partner firm wants a credential before it staffs you, earn it and still bring the org story. Company teams sometimes hire a strong administrator who has started writing Apex. That path works when the tests and the deployment habits grow up with the code.

Hiring onto a team that lives in the org

Resumes that land name an object, a user, and a rule. "Added a finance-approved discount on opportunity, enforced it in Apex with bulk tests, and surfaced it on the Lightning page reps use" is enough for a recruiter to forward. Mention industries only when you can say what the process needed. Partner experience and single-org experience are both valid. Say which you have, because a hiring manager at a company wants someone who will live with the automation for years, and a partner wants someone who can enter a strange org and find the customizations that will break an upgrade.

Loops may include a scenario in a developer org, a reading of a trigger, or a conversation about why you would not write Apex for a given request. Explain bulk behavior in plain language. Ask how changes reach production, how full the sandbox is, and who owns the data dictionary. Ask whether you will spend the year on new features or on untangling an older org. Both teach you, and they exhaust you differently. Ask how administrators and developers divide the work, because a team that lets every request become code will bury you, and a team that forbids Apex will ask you to fake a rule in a flow that cannot hold it. Say which balance you want.

Internal candidates often come from administration or business analysis. If that is you, pair the credential with one shipped Apex change and a sponsor who watched the deployment. If you are coming from another platform, learn the org's objects before you propose a new data model. Tell every employer your location and sponsorship limits early. A partner role may put you on customer sites or in a delivery queue. A company role may put you in the sales organization's calendar, including the week the quarter closes, when a page change is suddenly urgent. Ask what that week looks like before you treat the job as a quiet backlog.

From a trigger to stewardship of the org

Early work is a field, a page, a trigger with tests, and a deployment someone else supervises. You learn the org's naming habits and the integrations that fail when a field changes meaning. The next step is a feature the business runs on: the discount, the approval, the handoff to finance, with a page reps do not fight. Later you steward a slice of the org. You decide which customizations survive a platform release, you review other people's Apex for bulk trouble, and you keep the object model from forking. Some developers become the technical lead on a multi-cloud program inside the same customer. Some move into partner leadership. The common thread is an org that stays explainable.

Evidence is a rule the business still uses, tests that have caught a bad deployment, and a Lightning page a new rep can learn. Keep a short account of one customization you removed and one you defended. That pair shows judgment. When you want a broader seat, ask to own the deployment path and the review of Apex, and write the conventions the team will actually follow. A move to another cloud or another business unit inside the platform is a real fork. Take it for the domain, and leave the old object documented so discount still means what finance signed.

The long path stays inside the org. You handle larger rules, riskier integrations, and the politics of a field that three departments claim. People trust you after your deployments have been boring and after you have told a leader that a requested checkbox would split the meaning of a number the board already sees. Stay close enough to Apex and Lightning to review them fairly. The growth is a wider org whose records still match the process the business thinks it runs.

Reports and integrations tell you whether the org still means what the page says. After the discount ships, you check the report finance already trusts and confirm the new field rolls up the way they expect. You check the outbound message or the nightly extract that sends opportunities elsewhere, because a new required field can stall a load that used to succeed. You fix that in the same release when you can, and you warn the integration owner when you cannot. A Lightning page that looks right while the warehouse of records diverges is a demo the business will outgrow in a week. Stewardship includes those downstream readers, named in the deployment notes.

An Apex offer and the figures on the chart

The chart behind a Salesforce developer offer for Apex, Lightning, and org work is the broad web-developer market in the Bureau of Labor Statistics Occupational Employment and Wage Statistics for May 2025. The entry figure on that chart is $48,100. The national median is $92,650. The published gap between them is $44,550. A first platform seat, with a mentor on the deployment and a narrow Apex change, can sit near entry. Once you own a business rule in Apex, the Lightning page reps use, and the path into production, the median is a fair published anchor. If the offer remains at $48,100 while the req describes that ownership, place the $44,550 beside the opportunity story you already told.

Washington holds the highest median on the chart at $130,440. The gap from the national median to that highest state median is $37,790. Virginia's median is $128,380. California's median, typical pay in the state, is $119,570. California's published range tops out at $202,850 where the Bureau has enough people in the occupation to publish a figure. The gap from the national median to that high end is $110,200. A California offer near $119,570 is near typical pay. A conversation pointed at $202,850 is about the high end of the published range and belongs with scope at that far end, such as stewardship of a large org's Apex and release path. Washington's median outruns California's median and still describes typical pay in Washington, so quote it as a median.

Maryland's median is $112,690. Missouri's median is $103,750. Montana's median is the lowest on the chart at $62,060. For a Missouri company, $103,750 is the state line to master. For Montana, set the offer beside $62,060, and also beside the national entry figure and the national median, because $62,060 sits between $48,100 and $92,650. Virginia at $128,380 and Washington at $130,440 are a close pair. Choose between them with the org you will inherit, the deployment habits, and the city you will live in. When you stand up, name the Lightning page you will change and the single dollar line you compared, and keep that pair in your notes until the written offer matches it.

Careers related to Salesforce Developer