Adrien Valentin, Salesforce Application Architect

Salesforce architect with 11+ years in software engineering and 8+ years on the Salesforce platform. Master's degree in Computer Engineering (Efrei Paris, 2015), taught in English. 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 (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. 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, 587 opportunities generated: 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: Granular Automation Bypass (AG2R La Mondiale)

Summary: A fine-grained bypass mechanism, per validation rule, per trigger and per method. Lets a heavy integration run only what concerns it, and lets Apex code manipulate data without triggering unwanted side effects. Adopted as the standard across the Sales Cloud platform.

Problem: Two distinct needs, one root cause. First, heavy integrations were triggering automations irrelevant to their use case, burning CPU time and heap for nothing and risking platform limits. Second, legitimate Apex code was creating or modifying data without wanting a specific feature to fire. In both cases, a precise automation had to be neutralized from a precise context, without touching anything else.

Rejected approach: Creating dedicated static variables per feature, set by callers and checked by each automation. Rejected because it was not scalable and could not be integrated into the existing TriggerHandler framework: every new feature would have needed its own variable, with no generic mechanism to declare or check them.

Decision: A reusable bypass framework, with per-validation-rule, per-trigger and per-method granularity. Every bypass is declared explicitly, at exactly the scope required. Decision presented to and validated by the Design Authority, a three-person body meeting weekly to arbitrate cross-cutting topics, then adopted as the standard across the Sales Cloud platform.

Trade-off: More verbose to declare than a single switch: every scope must be named explicitly, and a forgotten bypass stays a forgotten bypass. In return, the scope is always readable, no automation is ever neutralized unintentionally, and a heavy integration no longer pays for code that has nothing to do with it.

Architecture Decision 3: PRM Data Model Migration (custom → standard Salesforce)

Problem: Fully 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. Triggers on Account, PartnerOrg__c and PartnerContact__c 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 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: 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.

Career Timeline

• 2015–2018, Dassault Systèmes: First steps in application architecture: technical referent 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 architecture 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 and Criteo (via Texeï): Cross-cutting Design Authority at AG2R La Mondiale: multi-team architecture governance, technical decision oversight, validation of the team's deliveries through Copado, including the Salesforce Industries (Vlocity) Insurance layer. International engagement at Criteo.
• 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.
• Architect Certifications obtained: Platform Developer I, Platform App Builder, Platform Data Architect, Platform Sharing and Visibility Architect, combined Application Architect, Platform Identity and Access Management Architect. Pursuing: System Architect (remaining: Development Lifecycle & Deployment, Integration 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