KernDX

Appearance

Fast Starts ​

Copy-paste-ready guides that get one KernDX capability working in about 30 minutes, with no prior framework knowledge needed. Each one is a self-contained walkthrough: the smallest example that runs, then the few options you'll actually reach for. New to KernDX? Start at the top and work down.

Namespaces in code samples: kern. on a class and kern__ on an object, field, or metadata type mark the managed package's namespace. On the managed package, framework references need those prefixes even where a sample omits them; repackaged under your own namespace, replace kern/kern__ with your prefix; on an unmanaged deploy, drop them. See How to read the code samples.

Start here: the daily drivers ​

These five are the spine of almost every KernDX project. Learn them first.

  • Trigger Actions: add behaviour to a trigger by creating a configuration record, with no trigger code to write. Each behaviour can be switched off without a deployment (a 4-level kill switch, the master off-switch you flip in an incident), and every bypass is audit-logged.
  • Selectors: one query class per object that respects the running user's field-level security (FLS = field-level security), is easy to swap out in tests, and catches mistyped field names at compile time.
  • DML: writes that enforce the current user's permissions and record sharing by default (USER_MODE), batched into one all-or-nothing transaction, with async saves and automatic parent-before-child ordering.
  • Security: field-level security and object permissions (FLS/CRUD: object create, read, update, delete) enforced by default. When a check is bypassed, the framework records the reason the caller gave.
  • Logging: structured logs you can search and keep, with one tracking ID that follows a single user action across triggers, queries, callouts, and jobs (a correlation ID), plus flood control. This is the replacement for System.debug.

Build features ​

Reach for these as you build out UI, integrations, and background work.

  • LWC: build Lightning components on ComponentBuilder (a base class with the common wiring already built in) and shared patterns, instead of starting from raw LightningElement.
  • Outbound APIs: callouts that survive flaky external systems. They retry on failure; after repeated failures they stop calling the failing system for a cool-off, then resume (a circuit breaker); a repeated request returns the first result instead of running twice (an idempotency key); and messages that fail every retry are set aside for inspection rather than lost (a dead-letter queue).
  • Inbound APIs: a two-class pattern for receiving REST calls. A small class carries exactly the fields to move in or out and converts itself to and from JSON (a DTO), and a duplicate request is recognised and answered safely with a 409 instead of running again.
  • Async Processing: chained queueables and batches, with one tracking ID (a correlation ID) threaded through the whole run so you can follow it end to end.
  • Feature Flags: switches that turn behaviour on or off per org or user from configuration, with no deployment needed to flip them.

Harden ​

Add governance and safety once the feature works.

  • Custom Validations: validation rules you define as configuration, that Flows can call and that return structured errors.
  • Resilience: circuit breakers (stop calling a failing system for a cool-off, then resume) and retry policies for downstream systems that fail under load.
  • Data Masking: field-level masking for logs and exports, so personal data and secrets are redacted by rule before they leave.
  • Test Data: builder-based test factories that avoid inline DML and keep working across namespaces.

CI & quality ​

Drop the framework's guardrails into your pipeline.

  • Code Scanning: PMD rulesets, an ESLint plugin, and secret scanning that run in your pipeline to catch problems before they merge.
  • E2E Testing: Playwright-first end-to-end tests that run against the deployed org, so you exercise the real UI.