Adrien Valentin — Senior Salesforce Architect

Salesforce architect with 11+ years in software engineering and 8+ years on the Salesforce platform. EFREI Paris 2015. Currently at Qonto (European B2B fintech, ~1,500 employees, 10+ markets) where I designed the entire internal Salesforce tooling ecosystem from scratch. I design, decide, build and ship to production — from data model to deployment.

Key Metrics — All Production Systems

• 129,552 leads processed by LAM in 6 months (711/day average) — plus reassignments
• 12,181 automatic reassignments by TMM in 6 months (66/day)
• 1,440 AsyncCollector executions/day since June 2025 — 0 crashes
• 3,188 Lead Company Infos created, 587 opportunities generated, 71 Closed Won (LCI)
• ~130 sales reps managed across 124 assignment groups (TMM)
• 1,500 restaurants in CSV import pipeline — 3 years in production, 0 data loss
• 96 fields tracked across 4 Salesforce objects (Enhanced History)
• Architecture to production in under 1 month for LCI (6 trigger handlers, 2 LWC, 1 batch)

Tool 1 — LAM Editor (Lead Assignment Management)

A complete rules engine built on Salesforce for managing lead assignment rules. The data model is hierarchical: Rule → Audience → Criteria, with self-referential recursion. The type system is polymorphic with IntervalType implementations for Number, String, Date, Boolean, and Reference fields, supporting Salesforce polymorphic fields with multi-level navigation.

Key feature: Gap Analysis via set inversion — detects populations not covered by any rule. Cross-rule validation finds overlaps, inclusions and duplicates between rules. Dynamic SOQL generation via a recursive SoqlNode tree (leaf-to-root traversal). ~8,000 lines of structured Apex in CTRL→SVE→UTL layers. LWC with custom LightningDatatable extension and custom cell types.

Impact: 129,552 leads processed in 6 months (711/day), 0 change requests since go-live, Product Managers fully autonomous on rule configuration. Deployed at a European B2B fintech (~1,500 employees, 10+ markets).

Tool 2 — AsyncCollector (Async Job Orchestrator)

A metadata-driven centralized orchestrator replacing N independent Salesforce Scheduled Apex jobs. Runs every minute via a single scheduled entry point. Orchestrates 5 critical jobs: Lead Assignment (LAM), Case Routing, Partner Sync, Opportunity Processing, Partnerstack. Configuration is 100% declarative via Custom Metadata (Features__mdt with asyncClassToBeCollected__c, asyncInterval__c, Enabled__c fields).

Architecture: Uses Type.forName().newInstance() to instantiate job classes dynamically. Tracks last execution per job in mLastExecutions map to enforce configurable delays. Utils.jobBeginWithIsScheduled() prevents duplicate concurrent executions. Auto-Kill pattern per job. Retry_Async Queueable retries DML on UNABLE_TO_LOCK_ROW up to 10 attempts. Error isolation: one failing job never blocks others.

Impact: 1,440 executions/day, 0 crashes since June 2025. 100% hand-coded without AI. In production since June 2025.

Tool 3 — TMM (Team Members Management)

Capacity planning tool for sales managers. Manages ~130 sales reps across 124 assignment groups in a European B2B fintech. Three-level model: Group → Member → Distribution (per object). Deficit-based assignment algorithm: always assigns to the member furthest below their target percentage, converging toward target distribution over time.

Dual inactivity circuit: manual vs automatic — fully independent. Virtual accounting for inactive members: their share is redistributed while they're absent, reactivated automatically on return without overloading. Automatic Outlook/Salesforce Calendar sync for absences. Optimized sharing refresh via intelligent delta diff (only changed records). LWC with tabbed interface, bi-modal management.

Impact: 12,181 automatic reassignments in 6 months (66/day). Coupled with LAM: 129,552 leads processed on the same period.

Tool 4 — LCI (Lead Company Info — Multi-Company Lead Model)

Architectural break from Salesforce's standard 1-Lead-1-Company constraint. A Lead becomes a Person linked to N independent Company Infos. Each LCI tracks its own company, SIRET, source, and partner attribution independently. 2-level matching: first the person (email/phone dedup), then the company (SIRET → normalized name → FindDuplicates API with fuzzy matching).

4 auto-conversion paths: existing customer (→ Contact), new customer (→ Lead), post-conversion (→ LCI), hourly batch cleanup. Multi-company conversion wizard: each LCI creates its own Account/Contact/Opportunity independently. 6 interconnected trigger handlers (Touchpoint, LCI, Lead, Contact, Account, Batch). Duplicate Rules with AUTOMATION prefix conditions leverage native SF fuzzy matching without impacting runtime.

Impact: In production since February 2026. Architecture to production in under 1 month. 3,188 LCIs created (66/day), 587 opportunities generated, 71 Closed Won — deals that would have been lost without this system. 18% of touchpoints involve a different company than the Lead's primary company — these opportunities were previously invisible.

Tool 5 — Enhanced History (Advanced Field History Tracking)

Enhanced Salesforce history view with dual perspective. View by field: history grouped by field, ordered by last modification date. View by transaction: history grouped by update datetime, showing all changes in a single operation together. Update Source custom field traces how a change happened: UI, API, Flow, Batch — full audit trail.

Sibling comparison feature detects data anomalies between similar records. Generic reusable LWC component deployable on any standard or custom Salesforce object. Zero additional custom objects — built entirely on native Field History Tracking. Configured via Custom Metadata + LWC parameters. 96 fields tracked: Lead (31), Account (50), Contact (2), Opportunity (13).

Architecture Decision 1 — Multi-Company Lead Model (Qonto, 2024)

Problem: Salesforce's standard model imposes 1 Lead = 1 company. When a prospect represents multiple companies, the intent signals from each company are lost. Allowing duplicate persons (1 lead per person/company pair) would let multiple sales reps prospect the same person without coordination, losing cross-company intelligence.

Rejected approach: Duplicate person records — 1 lead per (person, company) pair. Creates coordination failures and data fragmentation.

Decision: 1 Lead = 1 Person + N Company Infos decoupled. The standard 1-Lead-1-Company model is abandoned. 2-level matching: person first (email/phone), then company (SIRET → normalized name → FindDuplicates API).

Trade-off: Non-standard Salesforce model — 6 interconnected trigger handlers to maintain, multi-level matching logic. In return: complete cross-company view, zero person duplication. Less than 1 month from architecture to production.

Architecture Decision 2 — PRM Data Model Migration (custom → standard Salesforce)

Problem: 100% custom partner model (PartnerOrg__c, PartnerDeal__c, PartnerContact__c) — not extensible, no native partner portal, no PRM reporting. Hard constraint: the model feeds both Salesforce reports AND external systems — any migration must guarantee zero regression on traceability and figures, with ability to run parallel comparisons before cutover.

Rejected approach: Extending the custom model with new objects on a fragile base. Incompatible with Experience Cloud Partner Communities and native PRM reporting.

Decision: Migration to standard Salesforce PRM with a mandatory dual-write cohabitation phase. Account triggers (and PartnerOrg__c/PartnerContact__c triggers) maintain both systems in simultaneous sync — both are kept up to date. This enables parallel reporting (SF + external systems) to compare figures and prove parity before decommissioning anything.

Trade-off: Double trigger maintenance during cohabitation — increased complexity and divergence risk if an edge case is missed. In return: guaranteed cutover with no data loss, rollback always possible, native PRM features (partner portal, co-marketing, standard reporting). 3 phases, 3 custom objects → standard SF, 0 custom Apex triggers kept.

Architecture Decision 3 — CSV Delivery Plan Import Pipeline (Martin Brower, 2018-2021)

Problem: ~1,500 restaurants generate CSV delivery plans — each line represents a product type delivered on a given day in a time slot, with relative schedules (week 1, week 2, Monday…) without absolute dates. The import must create Salesforce records (Plan de commande + N Livraisons per restaurant) by projecting relative dates to absolute dates and applying business rules. Then a daily batch projects a rolling 1-week window, compares with D-1, and orchestrates an integration chain to an external system (volumes) and a route optimizer before CSV export and warehouse email delivery.

Rejected approach: Native Salesforce import (Data Loader, standard tools) — no partial error handling per restaurant, no unit rollback, no rules engine at import, impossible to chain integrations (volumes → optimizer) or monitor errors per batch.

Decision: Two distinct phases. Phase 1: custom import with projection engine (relative → absolute), centralized business rules (warnings/errors), total isolation per restaurant (1 batch = 1 SF transaction). Phase 2: daily batch projecting 1 rolling week, comparing with D-1 (notifications on changes), then orchestrating SF → External logistics system (volumes) → SF → Route optimizer → SF → CSV export + warehouse email.

Trade-off: Custom pipeline to maintain long-term (two phases, multiple point-to-point integrations). In return: centralized and testable business rules, total error isolation per restaurant, zero data loss over 3 years in production, output directly usable by warehouses. 1,500 restaurants, 3 years in production.

Architecture Decision 4 — Async Orchestration Without Conflicts (Qonto, 2023)

Problem: 5 critical jobs (lead assignment, case routing, partner sync, opportunities, deduplication) potentially executing in parallel — conflicts, execution duplicates, no coordination possible between jobs. Independent Scheduled Apex cannot prevent simultaneous executions of the same job, cannot manage inter-execution delays, and one job's error can block others.

Rejected approach: N independent Scheduled Apex jobs — no conflict prevention, no delay management, no error isolation.

Decision: A centralized metadata-driven orchestrator rather than N independent schedulers. AsyncCollector runs every minute — each job is declaratively configured (delay, lock, retry). Errors isolated per job. Practical application: Segment duplicates detected before Salesforce commit, suppressed without impacting user runtime.

Trade-off: Single point of control — if the collector stops, all jobs stop. Compensated by 0 crashes since June 2025 and 1,440 executions/day. Centralization gives complete visibility and coordination that N independent schedulers cannot provide.

Architecture Decision 5 — Design Authority (AG2R La Mondiale, 2021-2023)

Problem: Each project team arbitrated its own technical decisions in silos. Cross-cutting topics — integrations, data model, migration strategy — had no governance instance.

Decision: 3-person Design Authority: Technical Lead Salesforce (Adrien Valentin), Salesforce architect (consultant), sales/marketing tech lead. Weekly sessions, cross-cutting business and technical decisions.

Trade-off: Regular availability required from all 3 members. In return: guaranteed architectural consistency, reduction of cross-project decision debt.

Career Timeline

• 2015–2018 — Dassault Systèmes: First steps in application architecture — technical team leader on Biovia Content Manager, designed a contact management mobile application. Start of a structured approach to software design.
• 2018–2021 — Martin Brower France: First Salesforce architect role — data model design, architecture of a CSV import pipeline for ~1,500 restaurants (custom API, unit rollback per restaurant, job chaining, Bulk API 2.0). First structural build vs buy decisions.
• 2021–2023 — AG2R La Mondiale & Critéo (via Texeï): Cross-team Design Authority at AG2R La Mondiale — multi-team architecture arbitration, technical decision governance, Vlocity Insurance, Copado. International mission at Critéo.
• 2023–present — Qonto: Salesforce Architect — designed the complete internal technical ecosystem from scratch. Structural decisions: multi-company Lead model (LCI), metadata-driven async orchestrator (AsyncCollector), migration of custom PRM model → standard Salesforce.
• In progress — Architect Certifications: Platform Developer I → App Builder → Data Architecture → Sharing & Visibility → Application Architect → System Architect.

Philosophy

• Data model first — a bad foundation cannot be refactored in production
• Scalability, governance, observability by design — never retrofitted
• Every trade-off documented — silent decisions are expensive
• From whiteboard to production: I implement what I architect