ADL vs Salesforce
Salesforce Proved the Declared Application at Civilization Scale
TL;DR: The most successful declarative application platform in history is not a developer tool — it’s Salesforce. Custom objects, fields, validation rules, permission sets, Flows: all metadata, interpreted live by a multi-tenant runtime, no generated code. If you need proof that declared applications carry real businesses, Salesforce is that proof at a scale no one can argue with. It is also the same story’s cautionary ending: the richest declared vocabulary ever funded still ran out, and the overflow became Apex: a proprietary language, an entire profession, and an escape hatch that runs in system mode by default. Meanwhile the declaration itself lives in the vendor’s cloud, at per-seat rent, so unreadable as a whole that an industry exists just to turn it back into files. ADL is the same architecture with the file in your repo and the runtime on your metal.
The steelman
Salesforce’s own architects describe the platform the way this series describes Kalos: a metadata-driven kernel. When an admin creates a custom object, adds fields, writes a validation rule, or builds a Flow, no code is generated. A description is stored, and the runtime interprets it (into database behavior, API endpoints, security enforcement, and rendered screens) for every tenant, on every request. That architecture carried Salesforce from CRM vendor to the operating system of entire industries. Whatever else this essay argues, hold onto the headline: the largest enterprise-software success of the era is a declared application platform. The question “does description-executed-directly work in production?” was answered by the market, emphatically, years ago.
And its declared vocabulary is the richest in this series, further out than any fence we’ve mapped. Validation rules are real cross-field formula expressions with per-rule error messages. The permission model is genuinely deep: profiles and permission sets, field-level security, org-wide defaults, a role hierarchy, sharing rules. It’s a declarative security lattice more elaborate than most platforms ever attempt, ADL included. Flows give admins conditional, multi-step automation without code. Approval processes declare multi-stage review with record locking. Roll-up summary fields declare aggregations. Page layouts and the Lightning App Builder render working UI from metadata. That’s the one capability this series keeps conceding, and Salesforce actually ships it.
Every one of those is a point for the thesis. Which makes what happened next the most instructive data in enterprise software.
Even this vocabulary ran out, and the overflow became a profession
The pattern this series keeps finding (declaration describes, then the first requirement past the vocabulary becomes code) happened to Salesforce too. It just happened at such scale that the overflow got a name, a certification track, and a labor market: Apex.
Complex cross-record logic, integrations, aggregations beyond master-detail roll-ups, anything past formula expressiveness: it lands in Apex triggers and classes, a proprietary Java-like language that runs in exactly one company’s cloud. Mature orgs carry tens or hundreds of thousands of lines of it. The workaround pile didn’t just grow beside the platform; it professionalized.
Read the platform’s own fences around Apex as an architectural confession. Governor limits (hard caps on queries, DML, CPU per transaction) exist because arbitrary code in a shared runtime must be caged. Mandatory test coverage for production deployment exists because the platform knows the declared layer can’t see what the code does. And the sharpest edge, the one Salesforce security reviewers spend careers on: Apex runs in system mode by default. Unless the developer opts in (with sharing, explicit field-level-security enforcement), trigger and class code ignores the sharing rules and FLS that the declared layer so carefully expresses. The escape hatch is sovereign by default, and making it non-sovereign is a per-developer discipline, forever. That elaborate declared security lattice governs every request, except the ones your own code makes.
ADL’s escape hatch inverts that default. The Lua layer is sandboxed and instruction-limited, and writes go through the same pipeline (validation, permissions, audit) that governs every other request; opening raw access is an explicit, loudly-logged configuration choice, not the out-of-the-box behavior. Small vocabulary, non-sovereign hatch — or vast vocabulary, sovereign hatch. That’s the actual choice, and Salesforce is the honest evidence for what the second one costs.
The declaration you don’t hold, terminal form
An ADL domain is a file in your repository. A Salesforce org is thousands of metadata components living in the vendor’s cloud, edited through setup screens by years of hands, with no native, single, reviewable artifact that is the application. Ask the auditor’s question (what are the rules of this system?) and the answer is a guided tour: objects here, validation rules there, permission sets, sharing rules, Flows, approval processes, and the Apex that quietly overrides some of it.
The industry’s verdict on that arrangement is its own exhibit: an entire DevOps market (Salesforce DX, scratch orgs, and a tier of well-funded vendors) exists substantially to extract the org into version-controlled files so it can be diffed, reviewed, and deployed like software. Enterprises pay real money, per year, to approximate for their Salesforce org the property an ADL domain has by construction. When a market that size forms around recovering your own application’s definition, the definition was in the wrong place.
And the terms of residence compound: per-seat licensing that scales with your headcount forever, data behind metered APIs, and domain logic written in Apex and SOQL, portable to nowhere. The exit costs are not a bug in the business model.
The honest concessions
The biggest in the series, and all of them real.
The declared permission model outclasses ADL’s. Role hierarchies, org-wide defaults, sharing rules, per-field security across profiles and permission sets: Salesforce’s security lattice is deeper than ADL’s permissions vocabulary today, full stop. ADL’s counterargument is uniformity of enforcement, not richness of expression, and pretending otherwise would be noticed by every architect reading this.
Salesforce renders working UI from metadata. Kalos renders nothing. Page layouts, record pages, list views, an admin experience: declared and served. This is the recurring concession at its maximum: for the system-of-record-plus-screens problem, Salesforce ships both halves and Kalos ships one.
Trailhead built a labor market. Millions of trained admins and developers, certifications employers trust, a hiring pool in every city. ADL offers a spec learnable in a sitting, genuinely, but “learnable” competes with “already certified,” and buyers know which one de-risks a project on paper.
AppExchange and the operational moat. A vast ecosystem of vetted extensions, and multi-tenant operations with the compliance certifications regulated industries require, run by someone else, at a reliability bar a self-hosted runtime asks you to meet. For a CRM, buying Salesforce is usually simply correct; this essay’s argument begins where organizations start building their other systems inside it because it’s the platform they already have.
Closer
Salesforce settled the argument this series keeps making — the declared application won — and then demonstrated the two costs ADL exists to refuse: a sovereign escape hatch, and a definition that lives in someone else’s cloud at rent.