How to Become a Salesforce Developer in India

Most people who ask this question are not computer science graduates. They are working in support, BPO, manual testing, banking operations or back office, and they want to know whether the route into enterprise software is real or just marketing. It is real, but it is longer and more specific than most advertisements suggest. This post lays out what the work involves, the order the skills have to be learned in, which certifications carry weight, how to build project experience from zero, and what changes now that Data Cloud and Agentforce are part of the platform.

What a Salesforce developer does in a working week

A Salesforce developer builds and maintains business logic inside a customer's Salesforce org. The org already exists. Users are already in it. Your work sits on top of a live system that a sales team or a service team depends on every day.

In a typical week the work looks like this. A business analyst brings a requirement, for example that a case should escalate automatically when a high-value customer raises a second complaint in thirty days. You decide whether that is a Flow or an Apex trigger. If it is Apex, you write the trigger, put the logic in a handler class, query the related records in bulk, write a test class with positive and negative cases, and get it through code review. Another day you are fixing a callout to a payment API that started returning a 401 after a credential rotation. Another day you are building a Lightning Web Component so an agent can search external order data without leaving the case record.

The parts that take the most time are rarely the parts people study. Reading someone else's code. Reproducing a bug from a debug log. Understanding why a record is not visible to a user. Working out which of four existing automations on the same object is overwriting your field update.

How the developer role differs from the administrator role

Both roles work in the same org, often on the same object, sometimes on the same requirement. The difference is the tool they reach for and the point at which the platform stops handing them a button.

The honest summary is that a developer is an administrator who can also write code and understands what happens at runtime. Almost nothing on the admin side becomes irrelevant. A trigger that ignores sharing rules is a security defect. A batch class that ignores the org-wide default causes a data leak. The configuration knowledge stays with you.

Whether you need a computer science degree

You do not. Salesforce hiring in India runs on demonstrated platform skill far more than on degree stream. Commerce, science, arts and engineering graduates all sit in the same delivery teams.

Two caveats are worth stating plainly.

First, a few large service companies still apply degree filters at the campus and fresher intake level. You will not change that filter. You get past it by not entering through that door, and by having certifications and a portfolio that let you apply as an experienced lateral candidate rather than as a fresher.

Second, no degree does not mean no fundamentals. You will need the things a CS degree happens to teach: variables, data types, loops, conditionals, collections, classes and objects, and the difference between something running in a browser and something running on a server. If your background is non-technical, budget time for those before Apex rather than pretending they will arrive on their own. The syllabus sequence below puts them in the right place.

Why the admin-first path is not optional

People with a testing or support background often want to skip to Apex because coding feels like the valuable part. It goes badly, and for a structural reason.

Apex does not exist in isolation. Every line of Apex you write acts on objects, fields and relationships that an administrator defined, inside a security model that an administrator configured, alongside automations that an administrator built. If you do not know what a master-detail relationship does to sharing and to record deletion, you cannot predict what your trigger will do. If you do not know what a before-save Flow is already doing on that object, you will write code that fights it.

There is also an interview consequence. Developer interviews in India are heavily scenario based, and the scenarios are mixed. "The user cannot see the record, what do you check?" is an admin question inside a developer round. "Should this be a Flow or a trigger?" is a design question that assumes you know both. A candidate who only knows Apex answers half the paper.

The practical route is to become genuinely competent as an administrator, then add code. In most cases that also gives you a working option: admin roles are easier to enter from a non-IT background, and once you are inside a project you can learn development against real requirements.

The skill sequence, in order, with rough study hours

These hour figures are planning estimates for focused study with hands-on practice, not a promise. Two people move at different speeds. Use them to size the commitment and to notice when you are rushing a stage.

Stage 1: Platform, data model and security. Roughly 60 to 80 hours

CRM concepts, the multi-tenant architecture, the difference between metadata and data, orgs and sandboxes, and Lightning Experience navigation. Then the data model properly: standard and custom objects, every field type including formula and roll-up summary, lookup versus master-detail, junction objects for many-to-many, hierarchical and self relationships, cross-object formulas.

Then security, which is where most people are weakest. Profiles, permission sets, permission set groups, object-level and field-level security, then record-level security: org-wide defaults, role hierarchy, sharing rules, manual sharing, public groups, queues, restriction rules. Practise troubleshooting visibility. Given a user who cannot see a record, be able to walk down the chain and find the reason.

Stage 2: Customisation, data management and declarative automation. Roughly 50 to 70 hours

Page layouts, compact layouts, Lightning record pages, dynamic forms, record types and how they drive picklists and layouts, validation rules and formula functions, dependent picklists.

Data management on real volumes: Data Import Wizard, Data Loader for insert, update, upsert, delete, export and hard delete, external IDs and why upsert needs them, duplicate management, Workbench for SOQL and REST exploration.

Then Flow, which is now the centre of declarative automation. Variables and resources, decisions, loops, assignments, the record elements, and the flow types: screen, record-triggered, schedule-triggered, autolaunched and platform event-triggered. Before-save versus after-save and why before-save is cheaper. Scheduled paths, subflows, fault paths, error handling and debugging. Approval processes with multi-level and manager-based approvals.

At the end of this stage you can build a working application without writing code. That is the point at which the administrator certification is realistic.

Stage 3: Apex language fundamentals and SOQL. Roughly 80 to 100 hours

Apex execution context and governor limits first, before syntax, because they explain every rule that follows. Then variables, primitive types, operators, conditionals, loops, and the collections: List, Set, Map, and knowing which one a given problem needs. sObjects and schema information. DML through insert, update, delete, undelete, upsert and merge, then the Database methods, partial success, SaveResult and DML exception handling.

SOQL alongside it: filtering and ordering, parent-to-child and child-to-parent relationship queries, aggregate queries with GROUP BY and HAVING, dynamic SOQL and how to avoid injection, SOSL for cross-object search, and selective queries. The rule that never stops being tested is no SOQL and no DML inside a loop.

Object-oriented Apex closes the stage: classes, constructors, static versus instance methods, access modifiers, interfaces, abstract and virtual classes, wrapper classes, and the idea of service and selector layers.

Stage 4: Triggers, asynchronous Apex and testing. Roughly 70 to 90 hours

Triggers are where Apex meets the business. All seven events, the context variables, and the trigger handler pattern with one trigger per object. Bulkification until it is automatic. Real scenarios: field updates, related record creation, custom roll-up logic, duplicate prevention.

Asynchronous Apex next, because it is the standard answer to limits. Future methods and their restrictions, Queueable with chaining, Batch Apex with start, execute and finish and Database.QueryLocator, Schedulable with cron expressions. Be able to say why you would pick Queueable over future, and Batch over Queueable.

Testing is not optional and is not a formality. Test classes, test data creation, Test.startTest and Test.stopTest, meaningful assertions rather than coverage padding, testing triggers and each async type, and HttpCalloutMock for callouts. Then debugging: debug logs, the Developer Console, and reading a governor limit error properly.

Stage 5: JavaScript and Lightning Web Components. Roughly 90 to 120 hours

Do not skip the JavaScript. Variables and scope, functions and arrow functions, objects and arrays and their methods, destructuring and spread, template literals, promises and async/await, modules and imports. People who skip this stage write LWC by copying samples and cannot debug them.

Then LWC: the component bundle, naming and folder structure, the decorators @api and @wire, data binding, conditional rendering and iteration, custom events, parent to child and child to parent communication, and Lightning Message Service for components that are not related. Lightning Data Service and the record form components for simple CRUD, wired Apex versus imperative Apex and when each is right, error handling and loading states. Then the practical build work: datatables, search, filtering, sorting, pagination, modals, toasts, and NavigationMixin. Jest for component tests. Security throughout, because a component that calls Apex without CRUD and field-level security checks will fail review.

Stage 6: Integration. Roughly 70 to 90 hours

This is the stage that separates a platform developer from someone who only configures. Start with the concepts: inbound versus outbound, synchronous versus asynchronous, point-to-point versus middleware, real time versus batch.

Then the API surface: REST, SOAP, Bulk API and Bulk API 2.0, Composite, Metadata and Tooling. Authentication properly, because this is where interviews go deep: connected apps, OAuth 2.0, web server flow, JWT bearer flow, access tokens and refresh tokens, scopes.

Hands-on, call Salesforce from Postman first so you can see the request and response, then build callouts from Apex with the Http classes, serialise and deserialise JSON into wrapper classes, handle nested payloads and error responses, and parse XML for SOAP. Expose Salesforce with @RestResource and the HTTP method annotations. Use named credentials rather than hard-coded endpoints and secrets. Finish with event-driven integration: platform events, Change Data Capture, and where each fits against a callout.

Stage 7: Git, deployment and DevOps. Roughly 40 to 60 hours

Version control is now assumed even at junior level. Git clone, add, commit, push and pull, a .gitignore that suits Salesforce metadata, and a branching strategy with main, feature, release and hotfix branches. Merge versus rebase and conflict resolution.

Then Salesforce deployment: the environment chain from developer org and sandboxes to production, change sets and why teams move off them, Salesforce CLI and VS Code, source-driven development, DevOps Center. Pull requests, code review, automated test execution in a pipeline, validation before deployment, rollback strategy and post-deployment checks. Tool-specific knowledge of Copado, Gearset or Flosum is common in enterprise projects and is worth reading about once you have the Git and CLI base, though it is rarely a hiring gate for a first developer role.

Added up, the sequence is in the region of 450 to 600 hours of focused work before you are a credible junior developer candidate. Structure that however your life allows. What matters is that the stages stay in order.

The certifications that matter and the order to take them

Certifications in India do two jobs. They get your profile past a keyword filter, and they give a recruiter a reason to open your CV. They do not prove you can build anything, and interviewers know that.

Take them in this order.

1. Salesforce Certified Administrator. The base credential. Sit it at the end of Stage 2. Almost every Salesforce job description mentions it, including developer ones.
2. Salesforce Certified Platform App Builder. Declarative application building, data modelling and automation design. It is a natural extension of the admin work and it sits well on a profile that is moving toward development.
3. Salesforce Certified Platform Developer I. The one that changes how you are read. Apex, SOQL, triggers, asynchronous processing, testing and a component layer. Sit it after Stage 4, with some LWC exposure.
4. Salesforce Certified JavaScript Developer I. Optional but useful if your target is front-end heavy work. It is a genuine JavaScript exam, not a Salesforce exam with JavaScript in the title.
5. Salesforce Certified Platform Developer II. Later, once you have real project work behind you. It is not a fresher credential and attempting it early wastes money.

Two rules. Do not sit an exam you cannot back up in conversation, because the certification on the CV invites exactly the questions you have not prepared for. And keep your credentials maintained, since Salesforce expects release-based maintenance and an expired badge looks careless.

Exam fees, formats and retake policies change, so check the current details on Salesforce's own certification site before booking rather than trusting any article, including this one.

Building project experience when you have none

This is the real barrier, and it is solvable. The two tools are Trailhead and a free developer org.

Trailhead is Salesforce's own learning platform. Superbadges are the part that counts, because they are scenario based rather than quiz based and they require a working solution in an org. A profile with relevant superbadges and a reasonable rank tells a recruiter you have actually been inside the product. Trailhead alone is not enough, though, because the requirement is handed to you in neat steps and real requirements never are.

A developer org is free, permanent and yours. Sign up and build something end to end. The most useful shape is a single project that runs through every layer, along the lines the syllabus suggests: requirements and user stories first, then the data model with accounts, contacts, leads, opportunities, products, orders, cases and a couple of custom objects. Then admin configuration with users, profiles, permission sets, roles, org-wide defaults, sharing rules, record types, layouts and validation rules. Then automation with record-triggered and screen flows and an approval process. Then Apex with a trigger, a handler, a service class and an asynchronous job. Then a Lightning Web Component dashboard with search and a datatable. Then an integration in both directions using a named credential and an external REST API, with JSON parsing, error handling, logging and a retry. Then test classes and Jest tests. Then deployment through Git and the CLI.

That single project answers more interview questions than ten disconnected exercises, because every question about design has a real decision behind it that you made and can explain.

Two discipline points. Write the requirements down before you build, in user story form with acceptance criteria, and keep the document. Push everything to a public GitHub repository with a readable README, since a link is far stronger than a claim.

What you must not do is describe this as client work. The institute's trainers see the result of that constantly. Interviewers go five levels deep on a project claim: which table, what requirement, why this approach over that one, what exactly was your role. Fake project experience disappears at about level three. A well-built personal project honestly described survives all five levels, and it is more impressive than an invented client because the interviewer can tell the difference immediately.

What recruiters and interviewers filter on

The screening stage is mechanical. A recruiter scanning Salesforce profiles looks for certification names, specific technology keywords such as Apex, SOQL, LWC, triggers, integration, REST and Git, a public portfolio link, and location and notice period. If your CV says "worked on Salesforce" without naming the components, it does not survive the scan. Write the specifics.

The technical round is the opposite of mechanical, and it is where the filter really is. Interviewers ask scenario and debugging questions rather than definitions, because a definition can be memorised and a debugging answer cannot. "Your trigger is not firing, what do you check" is worth more to them than "what is a trigger".

The single most common failure the institute's trainers see is that candidates cannot defend their own resume. It lists more than they can explain. Somebody adds Batch Apex, platform events, Copado and Data Cloud to a CV because the job description mentioned them, and then the interview spends twenty minutes on the weakest item on the page. Cut your CV down to what you can discuss under pressure. A short honest profile that holds up beats a long one that collapses.

Two more things that carry weight. Specificity, meaning that every claim comes with a where and a why. And a clear answer structure: the situation, your approach, the reason you chose it, and the result. That beats a rambling reply on identical technical content.

What Data Cloud and Agentforce add

This is the newest layer of the platform and it is worth understanding early, because it changes what a senior Salesforce developer is expected to know.

Data Cloud brings customer data from many systems into one place inside Salesforce. The lifecycle runs from ingest to model to unify to analyse to segment to activate. Practically, you set up data streams from Salesforce objects, external systems, cloud storage and APIs. You map incoming data from data lake objects to data model objects. You run identity resolution with matching rules to combine records that refer to the same person into a unified profile. You build calculated insights, create segments, and activate those segments to targets outside Salesforce.

Agentforce is the AI agent layer that sits on top of that data. An agent is built from topics, instructions and actions. Actions are the important part for a developer, because they can be Flows, invocable Apex, prompt templates or external API calls. That means the agent is only as good as the automation and integration underneath it, which is exactly the work described in the stages above. Around it sits prompt engineering for agent and topic instructions, grounding with retrieval so answers come from enterprise documents rather than from the model's imagination, and the Einstein Trust Layer for masking, secure grounding and auditability.

The sequencing advice is simple. Do not start here. Data Cloud and Agentforce assume you already know the data model, security, Flow, Apex and integration, because everything they do is built on those. Learn the platform first, then add this layer, and you become a noticeably more valuable candidate. Start here first and you will be able to describe agents without being able to build the actions that make them work.

A realistic view of pay and where to start

One thing this post will not do is quote salary numbers. Pay for Salesforce roles in India varies by city, by company type, by your prior years of experience and by whether you enter as an admin or a developer, and any figure written in an article is out of date and averaged across situations that have nothing to do with yours. Check live listings on Naukri, LinkedIn and Indeed for your city and experience band, and look at what is being offered this month. That is the only number worth planning against.

What you can control is the sequence. Learn admin properly, add Apex and SOQL, add LWC, add integration, add Git and deployment. Certify at the points where you have actually earned it. Build one complete project in your own developer org and be able to defend every decision in it. Keep your CV to what you can explain.

If you would rather do that with a structured syllabus, a trainer to review your code and a project reviewed as though it were client work, our Salesforce training in Pune with placement support follows exactly this sequence, from admin fundamentals through Apex, LWC and integration to deployment.