Available for opportunities

Balram DhawanSalesforce architecture at scale.

Salesforce Technical Lead & Solution Architect (7x Certified) focused on data architecture, enterprise integrations, and performance optimization across multi-cloud implementations serving 12M+ users.

StackSalesforceExperience CloudPlatform EventsApexIntegrationsLDVGearsetBitbucket
Scroll
About

Salesforce at scale.
Data, integrations, performance.

I'm a Salesforce Technical Lead & Solution Architect focused on enterprise data architecture, integrations, and performance optimization across multi-cloud implementations serving 12M+ users.

My day-to-day is designing clean system boundaries: data models that survive LDV, sharing/security that stays understandable, and integration patterns (REST, async, event-driven) that don't collapse under volume.

I also care about delivery discipline — code reviews, CI/CD governance, and release strategy — so teams can move fast without losing control.

Domains

Sales CloudExperience CloudHealth CloudB2B CommerceData CloudPublic Sector

Architecture that survives scale

LDV strategy, data modeling, and security/sharing patterns that keep systems stable as usage grows into the millions.

Integrations you can trust

REST, async, and event-driven patterns (Platform Events) that decouple systems and behave under load.

Performance as a requirement

Indexing, query optimization, and pragmatic tuning decisions that deliver measurable wins (e.g. ~30% improvements) without compromising correctness.

Aug 2020 – Present

Lead Salesforce Consultant

Owned solution design across data modeling, sharing architecture, and integrations; led Experience Cloud programs serving 12M+ users; improved performance ~30% via indexing and query optimization; implemented delivery governance with Gearset + Bitbucket.

Mar 2018 – May 2020

Salesforce Developer

Designed B2B Commerce architecture (multi-warehouse pricing, cart sync), built secure Experience Cloud with dynamic profile/role design, and delivered scalable LWC solutions with integration flows and API-based synchronization.

Aug 2014 – Feb 2018

Software Developer

Built and maintained PHP/MySQL systems (CMS + subscription billing), plus internal dashboards and automation tools — strong fundamentals that still shape how I design platforms today.

Projects

Work that explains itself.

Delivery automation, document engines, voter-scale Experience Cloud, and integration architecture — including Platform Events and patterns that stay coherent as load grows.

Shipped

JIRA Dev Ready → E2E delivery agent

When a ticket hits Dev Ready, an agent drives implementation, opens a commit for human review, and hands off to CI/CD for the rest.

Problem

"Dev Ready" often stops at a green checkbox — someone still has to branch, implement, and babysit quality by hand. Manual handoffs dilute traceability and slow everything before tests even run.

Thinking

Use JIRA as the canonical trigger. When Dev Ready fires, an end-to-end agent picks up the spec, generates or updates the Salesforce-side work, pushes a commit, and stops at a human gate — developers review intent and risk; automation carries the repetitive verification.

Solution

Implemented an E2E agent wired to JIRA Dev Ready: it kicks off development work, pushes commits for developer review, then the pipeline runs code review rules, unit tests, Apex test classes, and whatever quality gates you already trust — same path every time, auditable from ticket to merge.

JIRASalesforceApexGitCI/CDQuality gates

Signals

Ticket-triggered delivery path
Human review before merge
Pipeline: tests + static checks

Scope note

Cloud names (Commerce, Sales, Experience, Health) reflect where the work lands — the stories above are written to be reviewable by engineers and hiring managers, not as marketing fluff.

Process

How I build systems.

The approach behind scalable Salesforce delivery: LDV-ready data design, secure sharing architecture, integration patterns that survive load, and release governance that keeps production predictable.

01
01

Architect for LDV and real users

Salesforce scale is a data problem first. I design with LDV in mind: selective indexing, query patterns, and bulk-safe processing so features hold up under real traffic.

# LDV checklist (conceptual)
- Data model: access paths are explicit
- Selective queries: indexed filters, skinny strategy where needed
- Bulk-safe automation: Batch / Queueable / async patterns
- Measure: slow queries -> fix with indexes + query design
02
02

Use OOTB first, customize deliberately

I start with standard capabilities (objects, security model, Flows, approvals, reports) and only add Apex/LWC when the platform can’t meet the requirement cleanly. It keeps orgs upgradeable, supportable, and fast to change.

# OOTB-first decision path (conceptual)
1) Can standard + config solve it?  -> do that
2) Can Flow solve it safely at scale? -> prefer Flow
3) Need custom UX/logic/perf?         -> LWC/Apex (bulk-safe)
03
03

Security and sharing are part of the design

Role hierarchy, sharing rules, and org-wide defaults shape everything. I build secure-by-default access with clear intent, and avoid performance traps in sharing-heavy models.

# Security architecture (conceptual)
OWD (baseline) + Role Hierarchy (org posture)
  + Sharing Rules (exceptions)
  + Permission Sets (capabilities)
  + Apex sharing (only when necessary)
04
04

Integration boundaries stay explicit

I use the right pattern for the job: synchronous REST for reads, async processing for throughput, and Platform Events when you need decoupling and resilience.

# Integration patterns (conceptual)
REST (sync)      -> immediate reads / commands
Async (Queueable)-> throughput + retries + back-pressure
Platform Events  -> decouple producers/consumers
05
05

Release governance is a feature

CI/CD isn’t optional at enterprise scale. I lean on code reviews, automated checks, and controlled releases (e.g. Gearset) so production stays boring.

# Delivery governance (conceptual)
PR review (humans)
  + automated checks (static + tests)
  + controlled deploys (Gearset / pipelines)
  + monitoring + rollback plan

Delivery

Design → build → release (governed)

Design reviewAlign on data model, sharing, and integration boundaries
BuildApex/LWC/flows built bulk-safe; integration contracts implemented
Quality gatesReview + automated checks + test strategy (incl. Apex tests)
ReleaseGoverned deploys (e.g. Gearset) with rollback and monitoring

Where high volume is involved, I prefer async + Platform Events to keep producers and consumers decoupled, with back-pressure and retries designed in.

Patterns

A simple Salesforce integration map

Contracts stay explicit

Channels

Experience · Mobile

Salesforce

Apex · LWC · Flows

Integrations

REST · Async · Events

Data + Scale

LDV · Indexes · Sharing

Sync (REST)
Async / Events
Governed
Contact

Say hello
if the work matches.

I'm strongest where Salesforce meets scale — Experience Cloud for millions of users, integrations that don't flake under load, and delivery patterns that survive audits and high scrutiny alike.

Chandigarh, India

  • Custom Experience Cloud — separate administration and public-facing portals built for real civic scale (~12M voters).
  • Integration-heavy delivery: APIs, enterprise patterns, and room to grow without painting yourself into a corner.
  • Scalability and operations in mind from day one — not a prototype dressed as production.

Domain expertise

B2B Commerce CloudSales CloudExperience CloudHealth CloudPublic SectorPublic sector portals

At a glance

~12M

Voter-scale audience on a customized Experience Cloud program — admin tools and public portal, one platform, integration-first.

Integrations · scalability · Platform Events

Commerce · Sales · Experience · Health · Public Sector