Salesforce Fundamentals is the foundation of understanding the platform. It focuses on its architecture, design principles, and key features that make it one of the most widely used CRM tools in the world.
Shared Infrastructure:
Data Isolation:
Automatic Upgrades:
Instead of hardcoding everything, Salesforce uses metadata to store configurations. This means:
Metadata enables low-code or no-code development, so you can make changes easily without deep technical knowledge.
Salesforce provides specialized solutions to meet different business needs. Each solution is a separate "cloud" tailored for specific purposes.
Sales Cloud:
Service Cloud:
Marketing Cloud:
Experience Cloud:
Extend Functionality:
Publish Your Own Apps:
Salesforce has a multi-layered security model to protect your data. Let’s explore the layers.
Hands-On Practice:
Trailhead Learning:
Think in Real-Life Terms:
Salesforce Fundamentals provide the foundation for understanding the platform, including its architecture, design principles, and core features.
Salesforce operates on a multitenant architecture, meaning multiple customers (or tenants) share the same infrastructure and application instance while keeping their data completely isolated. To ensure fair resource allocation and system stability, Salesforce enforces a series of Governor Limits.
Governor Limits are enforced to prevent any single tenant from monopolizing shared resources, ensuring optimal performance for all users. Key limitations include:
By adhering to best practices, developers can optimize their applications for performance and scalability while staying within the Salesforce limits.
Salesforce is metadata-driven, meaning configurations and customizations are stored as metadata rather than hardcoded in the application. This architecture allows for rapid application development and seamless upgrades.
Salesforce enhances flexibility through Dynamic Metadata, which allows users to modify UI components and field visibility dynamically.
Salesforce provides industry-specific cloud solutions in addition to its core offerings like Sales Cloud and Service Cloud.
Each of these industry clouds provides pre-configured objects, automation, and security features tailored to the specific needs of that industry.
Salesforce AppExchange is the platform’s online marketplace for finding and installing applications that extend Salesforce's functionality.
Salesforce applications on AppExchange are available in two types of packages:
Understanding package types is critical for deployment strategies, as managed packages are best for commercial distribution, while unmanaged packages are suited for internal use.
Salesforce’s security model is multi-layered, protecting data at multiple levels. In addition to object-level, field-level, and record-level security, two additional security features are important for protecting sensitive data.
Salesforce provides Session Management Features to enhance security, including:
Session Timeout Policies
Session Security Levels
To ensure data security, Salesforce provides Shield Platform Encryption, which enables encryption of sensitive data at rest.
What Can Be Encrypted?
Encryption Types
The additional topics covered in this section enhance our understanding of Salesforce's core concepts and deployment strategies:
When should I stay declarative in Salesforce, and when is Apex the better choice?
Start with declarative tools when they can meet the requirement cleanly, maintainably, and within platform limits. Move to Apex only when you need capabilities Flow and other builders cannot reliably provide, such as complex transaction control, specialized integrations, or advanced logic reuse.
This is one of the most common Platform App Builder judgment calls because Salesforce’s own platform guidance favors declarative customization first. Flow, Lightning App Builder, validation rules, formulas, and standard automation are faster to build, easier for admins to maintain, and usually better aligned with exam scenarios. Apex becomes the right answer when requirements exceed declarative boundaries: for example, custom callout handling, complex multi-object logic, precise exception handling, or reusable code services. A good exam clue is whether the requirement sounds like “clicks can do it safely” or “clicks would be brittle, duplicated, or impossible.” A common mistake is choosing Apex just because it feels more flexible, even when Flow or standard features would solve the problem with less risk.
Demand Score: 74
Exam Relevance Score: 90
For an outbound webhook-style integration, should I build everything in Apex triggers?
Not by default. First check whether a declarative option such as Flow plus an invocable action, or even a standard outbound mechanism, can meet the requirement. Use Apex triggers only when you need behavior that declarative tools cannot provide safely or clearly.
This question shows the boundary between “possible” and “appropriate.” Community answers often point out that admins overreach into trigger-based solutions when a more supportable design exists. In many orgs, Flow can orchestrate the business event while invocable Apex handles the technical piece, giving you reuse and admin visibility. Standard platform features can also be enough in simpler cases. Apex triggers make more sense when the logic must run in a very controlled transaction context, requires advanced coding patterns, or cannot be expressed declaratively without becoming fragile. On the exam, if the requirement emphasizes maintainability, admin ownership, and no-code configuration, favor declarative tools. If it emphasizes custom protocol handling or logic complexity, Apex becomes more defensible.
Demand Score: 67
Exam Relevance Score: 83
When installing an AppExchange package, why do admins care about install scope and org prerequisites?
Because package installation does not just add features; it also interacts with permissions, org configuration, and sometimes prerequisite platform settings. Install scope affects who gets access immediately, while missing org features can block installation or post-install use.
This is a practical admin concern that maps well to the exam’s AppExchange objective. “Install for All Users” and “Admin Only” are not just convenience choices; they change how quickly users can access package components and how tightly admins can stage rollout. Community questions also show that managed package installs can fail if the target org is missing a required feature, such as a dependency on a standard capability. The exam usually rewards the safer governance answer: install conservatively, validate prerequisites, and grant access intentionally through profiles or permission sets rather than broadly by accident. A common mistake is treating AppExchange as one-click with no governance impact. In reality, package deployment is part product evaluation, part security planning, and part change management.
Demand Score: 56
Exam Relevance Score: 76