Salesforce Admin + Developer Training in Pune with Placement

What a CRM is for before any of Salesforce's vocabulary is used — the business problem of one customer record shared across sales, service and marketing, and why companies buy a platform rather than build one. The product map follows so that later choices are informed: Sales Cloud, Service Cloud, Experience Cloud, Marketing Cloud and Data Cloud, and which of them Pune delivery teams actually staff for.

The org is then set up the way you will use it for the next twelve weeks: a free Developer Edition org, a Trailhead account, Setup and the object manager, and the Lightning Experience interface. The admin and developer split is made explicit — what is configured and what is coded — along with the sandbox and production distinction, release cycles, and how to read Salesforce's own documentation and release notes, which is a working skill in itself.

The standard object model first, because everything else sits on it: Account, Contact, Lead, Opportunity, Case and the record lifecycle each one implies, including the conversion path from Lead to Account, Contact and Opportunity that trips up newcomers.

Custom objects and the full field-type tour follow, with the choices that are expensive to reverse called out — picklist against text, currency and roll-up behaviour, and the external ID that makes an integration idempotent. Relationships are the heart of the module: lookup against master-detail, what cascade delete and roll-up summary fields buy you, the many-to-many junction object, hierarchical relationships on User, and schema-builder diagrams. The module closes on schema design from a written brief, and on the limits that shape it — field counts, object counts and record types.

The single largest area in the ADM 201 exam and the one Pune interviews probe hardest, taught as the layered model it actually is: what you can log into, then what objects and fields you can touch, then which records. Licences, profiles, permission sets and permission set groups with muting, built the modern way — a minimal profile plus permission sets — because Salesforce is winding permissions down on profiles in favour of permission sets.

Record access is then built from the outside in: organisation-wide defaults set restrictively, the role hierarchy opening access upward, sharing rules and criteria-based sharing widening it sideways, teams and manual sharing for exceptions, and Apex managed sharing where declarative tools run out. Field-level security, login IP ranges, multi-factor authentication, and the 'why can this user see this record' diagnosis exercise close the module.

Shaping what a user sees, which is most of what an administrator is asked for day to day. Page layouts and compact layouts, Lightning record pages assembled in the App Builder, dynamic forms and dynamic actions so that fields and buttons appear by condition rather than by profile-specific layout sprawl, and component visibility rules.

Record types and business processes then handle the case where one object serves two different teams with different picklist values and different page layouts — the pattern behind a large share of real org design. Lightning apps and navigation, list views with filters and inline editing, global and quick actions, path and kanban views, and mobile layout considerations complete the module, along with the discipline of designing for the user's actual task rather than exposing every field on the object.

The formula language, given a module of its own because it is a screen-out question in Pune Salesforce interviews and because it reappears in validation rules, flows, reports and Lightning page visibility. Operators and functions across text, number, date and logic; `IF`, `CASE`, `ISBLANK` against `ISNULL`, `PRIORVALUE` and `ISCHANGED`; cross-object formulas that traverse a lookup; and formulas that return an image or a hyperlink for a genuinely more usable record page.

Validation rules are then written as the inverse of a formula — a rule fires when the expression evaluates to true — with the error placement and message wording that makes the difference between a helpful guard rail and a support ticket. Roll-up summaries, the compile-size limit, and the debugging method for a formula that returns the wrong answer close the module.

Flow is now the automation tool, and this module is built on that: Workflow Rules and Process Builder were retired at the end of 2025, so they are covered only far enough that you can read and migrate the ones still sitting in older Pune orgs. Record-triggered flows are taught with the before-save against after-save distinction made concrete, because a before-save update on the same record is an order of magnitude cheaper and is the answer an interviewer is listening for.

Screen flows build guided interfaces, scheduled flows handle batch work, and autolaunched and platform-event-triggered flows are called from elsewhere. Elements, variables, collections, loops and fault paths are worked through, then the parts that separate a flow that survives from one that does not: bulkification, the entry-condition and run-once discipline, the flow trigger explorer for ordering, subflows for reuse, error handling that notifies somebody, and debugging with the flow debugger and the debug log. Approval processes and Flow Orchestration close the module.

Loading, moving and trusting the data, which is where a real implementation spends more time than anyone budgets for. The Data Import Wizard and Data Loader compared on when each is right, then the mechanics that matter: field mapping, upsert against insert, external IDs as the key that makes a reload safe, record owner assignment, and turning automation off for a bulk load so a trigger does not fire ten thousand times.

Data quality follows — duplicate and matching rules, merge behaviour, required-field and validation strategy for imported data, and normalising picklist values that arrived as free text. The module closes on the operational side: data export and the weekly export service, backup and the honest fact that Salesforce's own recycle bin is not a backup, mass transfer and mass delete, storage limits, and the data-privacy obligations under India's DPDP Act when a sandbox holds real customer records.

The output business users actually judge an org by. Report types and the custom report type that unlocks a cross-object question, then the four formats — tabular, summary, matrix and joined — chosen by the question being asked rather than by habit. Filters, filter logic, cross filters and the 'records without related records' pattern that answers most churn and gap questions.

Bucket columns, row-level formulas, summary formulas, groupings and charts follow; then dashboards with dynamic dashboards that run as the viewing user, filters, component types and refresh behaviour. Sharing and folder access is treated as a security topic rather than an afterthought, subscriptions and scheduled reports deliver the numbers without anyone logging in, and the module closes on report performance on large data volumes and on CRM Analytics at orientation depth.

The developer half opens here, and it opens gently: the first sessions are programming foundations for the roughly forty per cent of each batch who arrive from commerce, science or operations backgrounds — variables, control flow, methods and objects — before any Apex-specific syntax. Java developers move through this in a session and go deeper on the platform specifics instead.

Apex itself is then covered as the strongly typed, Java-like language it is: primitives and sObjects, collections and when a Map is the right answer, classes, interfaces and inheritance, static against instance context, properties, exceptions and custom exception types, and the developer console, VS Code with the Salesforce Extension Pack and anonymous Apex as the working environment. The execution context is introduced early because everything later depends on it: what one transaction is, and what shares its limits.

Getting data out of the platform. SOQL from the basics through the parts that carry marks and interview questions: parent-to-child and child-to-parent traversal, relationship queries, aggregate queries with `GROUP BY` and `HAVING`, date literals, `FOR UPDATE` locking, and binding variables safely.

SOSL covers the cross-object text search that SOQL cannot do. The selectivity discussion is where this module earns its place: what makes a filter selective, custom indexes, skinny tables, the query optimiser, and the non-selective query error that appears the first time a student's code meets a real data volume. Query plans are read in the developer console, and the module closes on the security layer developers most often skip — `WITH USER_MODE`, `WITH SECURITY_ENFORCED`, `stripInaccessible` and the sharing keywords that decide whose access an Apex class runs under.

Trigger context first — before and after, insert, update, delete, undelete, `Trigger.new` against `Trigger.oldMap`, and which context can modify the record without a further DML statement. Then the discipline that separates production code from tutorial code: one trigger per object, no business logic inside the trigger, and a handler class that the trigger delegates to.

A handler framework is built in class rather than described, with a recursion guard, a bypass switch for data loads, and a clear separation between trigger, handler and service layers. Bulk safety is drilled until it is reflex — never a query or DML inside a loop, always build a collection and act on it once — using deliberately unsafe code refactored under a two-hundred-record load. The order of execution is then walked end to end, because it explains almost every 'my validation rule fired before my flow' question, and the module closes on trigger and flow coexisting in one org without fighting.

Governor limits are the concept Salesforce developers are most reliably tested on, so they are taught by cause rather than as a table to memorise: multi-tenancy, what counts as one transaction, and which limits are per transaction against per day. Limit methods, the debug log's limit section, and deliberately breaching each major limit in a scratch exercise so the error message is familiar before it appears in production.

Asynchronous Apex then follows as the answer to most limit problems: Queueable with chaining and finalizers, Batch Apex with `start`, `execute` and `finish` for large volumes, Scheduled Apex, and future methods with an honest account of why they are mostly legacy now. Testing closes the module and it is treated as design rather than as a coverage tax — test data factories, `Test.startTest` and `stopTest`, `System.Assert` with meaningful messages, mocking callouts, testing as a specific user, negative and bulk tests, and why seventy-five per cent coverage is a deployment gate rather than a quality bar.

The modern UI layer, built on web standards rather than a proprietary framework. Component structure and the module bundle, templates and directives, reactivity and the `@api`, `@track` and `@wire` decorators, and the lifecycle hooks with the render cycle they belong to. Parent-to-child through public properties and methods, child-to-parent through custom events, and the Lightning Message Service for components with no relationship to each other.

Data access is covered both ways — Lightning Data Service through `lightning/uiRecordApi` for record work without Apex, and wired or imperative Apex when the question is more complex — with the caching difference between them made explicit. The Salesforce Lightning Design System, base components and accessibility follow, then Jest unit tests with `sfdx-lwc-jest`, error and loading states, navigation, and surfacing a component on a record page, an app page and a screen flow.

Salesforce is rarely the only system in the estate, and integration work is a large share of Pune Salesforce delivery. Outbound first: named credentials and external credentials as the modern way to hold an endpoint and its authentication, HTTP callouts from Apex, callouts from a flow, JSON serialisation and deserialisation, the callout limits, and mocking a callout in tests because a real one is not allowed there.

Inbound covers the REST and SOAP APIs, custom Apex REST endpoints, Composite and Bulk API 2.0 for volume, and Connected Apps with the OAuth flows a client actually uses. Event-driven integration then covers Platform Events, Change Data Capture and the Pub/Sub API, followed by External Services from an OpenAPI specification and Salesforce Connect for external objects. The module closes on the failure modes: retries, idempotency, error logging and the integration user's permissions.

How work actually reaches production, which is the part self-taught candidates most often cannot answer. Sandbox types and what each is for — Developer, Developer Pro, Partial Copy and Full — refresh cadence, sandbox seeding and masking real data, and designing an environment path rather than developing in production.

The modern toolchain is then used rather than described: Salesforce CLI, source format and the project structure, scratch orgs and source tracking, retrieving and deploying metadata, and Git with branches and pull requests holding the org's real history. Change sets are covered as the legacy path still in use at many Pune accounts, unlocked packages as the modular alternative, and a deployment is automated in GitHub Actions with tests as the gate. The module closes on release governance — destructive changes, deployment failures and how to read them, and the release-window discipline that keeps a Friday deploy from becoming a weekend.

The platform's AI layer, at the depth that lets you hold a credible conversation in an interview and configure a working example — not architect-level depth, which is a separate specialisation. Data Cloud first, because the rest depends on it: data streams, data model objects, identity resolution and calculated insights, and why a customer data platform sits underneath the AI story rather than beside it.

Einstein features that ship with the clouds are then configured — scoring, prediction and conversation tooling — followed by Prompt Builder for grounded prompt templates that reference real record data, and the Einstein Trust Layer, whose masking, zero-retention and audit properties are the first question an Indian BFSI or healthcare client asks. Agentforce closes the module: agent topics, actions backed by Flow and Apex, testing an agent's behaviour, and an honest account of where an agent is the wrong answer.

The capstone runs the whole course through one org: a schema modelled from a written brief, a security model with organisation-wide defaults and permission sets, dynamic Lightning pages, validation rules, record-triggered and screen flows, a bulk-safe Apex trigger framework with tests above ninety per cent, an LWC front end with Jest tests, one outbound integration behind a named credential, reports and dashboards for the business owner, and the whole thing in a Git repository deployed through a sandbox with a README a stranger can follow.

Certification preparation runs alongside it: full timed mock exams for ADM 201 and Platform Developer I, a weak-area review driven by the mock results rather than by the syllabus order, and the Trailhead Superbadges hiring managers look for. Interview preparation targets what Pune panels actually ask — walk through your order of execution, why this flow is before-save, how you would make this trigger bulk-safe, and how you would move it to production — with resume, LinkedIn and GitHub rewritten around the capstone and two mock interviews recorded and reviewed.