Stories tagged platform-limits

The Winter Twenty Seven release increases the synchronous Apex heap limit from six megabytes to ten megabytes and raises the asynchronous limit from twelve megabytes to twenty-five megabytes. To manage the transition safely, administrators can use Apex Settings to force non-production orgs to retain the previous Summer Twenty Six limits until code is verified against the new thresholds.

Testing with large compressed files shows that the additional memory allows significantly larger payloads to be processed in a single transaction, though compression algorithms and file structure still dictate actual heap consumption. The author notes that higher memory availability does not automatically improve throughput, as CPU limits and governor constraints remain unchanged.

Larger heaps introduce risks such as overwhelming end users with unfiltered data tables, overloading downstream APIs, or masking existing logic flaws that previously failed at smaller record counts. The article concludes that developers should continue writing code that conserves resources and batches workloads, treating the increased limits as capacity for legitimate growth rather than a target to hit routinely.

The author proposes Framework-Driven Development as a response to the risks of AI-assisted coding on the Salesforce platform. Because large language models generate probabilistic output that often ignores existing architecture, developers risk introducing inefficient code that consumes shared governor limits. The approach shifts responsibility for code quality and performance from individual engineers to the underlying framework itself.

Framework-Driven Development relies on three main assumptions. Interfaces must be deliberately restricted so that neither developers nor AI agents can bypass established rules. Internal logic should automatically optimize queries and data operations to respect platform boundaries. Finally, quality must be baked into the design through compile-time contracts and runtime validation that force explicit overrides when defaults are intentionally ignored.

Real-world implementations demonstrate these principles through specialized libraries. A trigger handler restricts available methods based on execution context, preventing invalid database operations before compilation. A query builder enforces caching rules and blocks complex nested conditions that could return misleading results. A data manipulation layer chains operations safely while managing sharing modes and commit strategies. Each component throws descriptive exceptions when misused, requiring deliberate action to bypass safeguards.

The methodology also emphasizes comprehensive documentation and structured prompts to guide artificial intelligence tools. By exposing only safe public methods and providing clear usage examples, teams can maintain consistent standards across multiple projects. This reduces technical debt and ensures that automated code generation aligns with enterprise architecture requirements.