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 review—Align on data model, sharing, and integration boundaries
Build—Apex/LWC/flows built bulk-safe; integration contracts implemented
Quality gates—Review + automated checks + test strategy (incl. Apex tests)
Release—Governed 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