Multitenancy is platform-level architecture, not a feature to configure. The work is designing solutions that respect the constraints.
- Bulkify all code
Apex code must handle 200 records as efficiently as one. SOQL inside loops, DML inside loops, both fail bulk scenarios. Use Map-based patterns.
- Respect governor limits
100 SOQL queries, 150 DML statements, 10s CPU, 6MB heap per synchronous transaction. Design within these caps; reach for async (Queueable, Batchable) when needed.
- Use metadata, not code, for customization
Custom fields, flows, validation rules are the primary customization tools. Reserve Apex for cases where declarative tools genuinely fall short.
- Design for selectivity
SOQL queries must be selective (filter on indexed fields). High-volume scans hit the selectivity threshold and fail.
- Plan for shared release schedules
Salesforce releases are platform-wide. Test in sandbox before each major release; surprises in production are not the customer''s fault but are the customer''s problem.
- Architect with the constraints in mind
Multitenancy is non-negotiable. Every architectural decision must respect it; trying to bypass produces fragile solutions.
- Multitenancy constraints feel restrictive compared to single-tenant platforms. They''re non-negotiable; design within them rather than fighting them.
- Governor limits cannot be increased per-org. Salesforce Support cannot raise them; redesign is the only path.
- Per-tenant code branches do not exist. Customization happens through metadata configuration; trying to clone per-customer is anti-architectural.
- Performance varies by org due to shared infrastructure. A neighboring tenant''s heavy work can produce transient slowness; not always under your control.