Saturday, 3 October 2026Sat, 3 Oct 2026

Thresholds, defaults and feature switches tend to get typed straight into whichever formula, Flow or Apex class needs them. The cost shows up later, when the business changes a number and someone has to find every place it was used. Andrew Fawcett argues that Custom Metadata Types are the platform’s answer: a single, deployable home for those values that travels through source control with the rest of the application, unlike records in a Custom Object or Custom Settings.

The post works through a deal-policy example. A Deal_Policy__mdt type holds a large-deal amount, a maximum discount, a default discount and an approval threshold, with one record per region and a Default record for org-wide values. A Formula Field reads the Default record directly using the $CustomMetadata reference, which names the type, the record and the field. The same shape works in Validation Rules and field defaults, though long text area fields cannot be referenced this way.

From there it covers each consumer in turn: formulas, Validation Rules, Flow, Apex, Lightning Record Pages and Agentforce, noting which support the reference natively and which need a workaround. A sample project deploys to a Scratch Org so readers can follow the same Setup paths. The harder question the post keeps returning to is impact: once the value lives in one place, how do you find out what reads it and what changes when you edit it.

Starting in Winter ’27, users can select several records in a List View or a Related List and hand them to a Screen Flow that opens in a modal. The article treats it as an overlooked part of a large release because it lets admins build mass actions without code.

The setup has one detail that is easy to miss. The flow needs a text collection variable named ids, in lowercase, marked as available for input. The selected record Ids arrive in that variable. The example flow gets the matching Contacts, shows them in an editable Data Table on a screen, and writes the edits back with an Update Records element, with fault paths on the data elements.

To expose it, create an action of type Flow on the object and add it to the List View Button Layout under the Lightning Experience List View actions. For Related Lists, create the same kind of action, then add it to a Dynamic Related List – Single component on the parent’s Lightning Record Page.

Salesforce engineers describe building Assistive Authoring for Prompt Builder, which turns a plain-English requirement into a working Prompt Template in under a minute instead of the roughly 25 minutes an experienced admin needs today. The core risk they targeted was not obviously bad output but plausible-looking templates that break at runtime because the model invented a field, corrupted a record ID, or returned malformed metadata.

The solution uses Agent Graph to split the work into a router node and three specialized sub-agents for generating, refining, and clarifying requests. State variables carry client-supplied and runtime context, bound inputs pass only what each tool needs, and four backend tools run in a fixed sequence with a beforeReasoning hook that fetches grounding before the model loop starts, cutting latency by removing a model decision from the critical path.

Deterministic boundaries protect the three failure points. The model can signal intent through a state variable, but the graph evaluates guards before changing nodes. The model never touches record IDs; it writes stable developer names and a server-side transpose layer maps them back to real records and IDs. Template metadata is wrapped in sentinel tags, the client extracts and parses only that payload, and parse failures return errors rather than guesses.

Grounding is handled by a discovery service that normalizes SObject fields, flows, Apex-backed providers, and search retrievers into one consistent shape, runs in the current user’s context with field-level readability filtering, and reduces the result to an allowlist the model must select from. Safety is enforced by making output a draft only: the agent has no tool to save, publish, or execute, content becomes typed editor blocks with escaped interpolation, and the admin accepts or rejects a diff before anything is saved.

The article profiles Agent Designer, an internal Marketing Cloud system that automates the design, verification, testing, and repair of multi-agent AI teams, reducing the cycle from two to four hours to roughly 15 to 30 minutes. Engineers previously hand-authored YAML files, prompts, profiles, tools, models, budgets, and turn limits, then tested and iterated manually. The new system uses an orchestrator that dispatches and verifies work but is prohibited from writing any agent file, supported by seven specialists that each carry their own model, budget, and turn limit, and it has helped about 200 engineers adopt a manager-of-agents model.

Multi-agent governance proved harder than single-agent configuration because independently valid specialist outputs can combine into an unbuildable design. Architecture, failure-mode, and compliance analysts work in parallel without seeing each other’s findings, so the orchestrator must detect contradictions and apply bounded remediation rather than restarting the analysis. Since the agent specification lacked a native write-scope field, write boundaries are enforced in prompts, and teams created through Claude Unleashed must define exactly one coordinator and pass a compatibility validation.

Budget enforcement is topology-specific: a flat check for a single agent, items times cost times steps for a swarm, and whole-roster ceilings for a team, all fitting inside the orchestrator’s 500-turn budget that is divided across analysis, approval, generation, testing, and retries. Verifiers return structured PASS, WARN, or FAIL blocks with rules such as warning rather than failing when uncertain, and the orchestrator runs a meta-check across their outputs. A test doctor classifies failures into categories including soft failures that require point-by-point comparison against expected behavior, and self-healing is capped at two fix attempts and a three-dollar ceiling before the system stops and escalates to a human.

Agentforce Coworker is presented as one of three pillars of AIforce, the interface layer announced at Dreamforce ’26 that sits on top of Agentforce, Customer 360 and Data 360. Its purpose is to reduce swivel-chairing between applications and to act as a router for a growing agentic workforce, so users do not have to know which agent handles which task. It offers three interaction modes: Find for natural-language queries across CRM, Slack, files, knowledge bases and 270+ connected sources; Catch Up for proactively surfacing changes that occurred while the user was away; and Plan and Act for outcome-level instructions that Coworker orchestrates across agents.

The article describes the trust model as reusing the existing Salesforce metadata-driven security: Profiles, Permission Sets and Sharing Rules still apply, so the agent operates under the same least-privilege constraints as users. Setup requires Data 360 to be enabled first, since it indexes CRM data and enforces governance, then assigning the Agentforce Coworker Admin Permission Set, enabling the feature through Salesforce Go, optionally granting additional data sources under Manage Data, and finally assigning the Agentforce Coworker User Permission Set to end users. The author cautions that orgs need clean data and properly configured permissions before enabling it, and notes the user-facing entry point is a new Ask button next to global search in Lightning Experience, with availability also in Microsoft Teams.

Cloud Atlas is the globally distributed identity data store behind a large share of Salesforce logins and token validations, run to five nines of availability. In this interview, the team’s engineering lead explains why overload at that layer is dangerous: slow responses cause upstream services to retry, the retries add traffic to a system already under pressure, and a local bottleneck spreads. Agent-driven and automated workloads have made traffic burstier and harder to predict than human logins.

The old protection was per-instance rate limiting. That held up while infrastructure was static, but with autoscaling each server’s limits went stale whenever instances were added or removed, and each server knew only its own load rather than a customer’s total usage across the fleet. Busy servers rejected requests while capacity sat idle elsewhere, and one tenant’s spike could still starve others.

The redesign protects the service as a whole instead of individual servers. It combines global quota management that needs no central coordinator with load shedding that acts before retries begin to amplify the overload, so a single customer’s surge is isolated rather than shared.