Salesforce Core Fundamentals: Data Modeling & Security
Introduction
Salesforce isn’t just a CRM. It's a platform that combines two approaches: low-code and code.
In Salesforce, there are administrators. They create roles, write validation rules, build objects and fields, and best of all, they do all of this without writing one line of code. There are also developers. These are the people who solve problems that cannot be solved using declarative tools. They do this using Apex, SOQL, SOSL, and LWC.
In addition to administrators and developers, there is a third level of interaction with the system: Agentforce 360. These are autonomous AI agents that work alongside humans: they read metadata, call APIs, and make decisions.
Data Modeling & Business Process Automation
Under the hood, Salesforce is a multitenant cloud platform where multiple customers share the same underlying infrastructure and database architecture. Customer data is isolated at the organization level: each organization has its own identifier (Org ID). Each organization’s settings - such as objects, fields, and automations - are stored as metadata, making Salesforce a platform that manages this metadata. Millions of users can work on a single platform, but their data remains isolated from one another.
Standard vs Custom Objects
When you create your Salesforce org, the first thing you’ll encounter is objects. Objects are key components of any organization - not only in Salesforce but in any database. Simply put, an object is where all your information is stored. In Salesforce, there are two types of objects: Standard Objects and Custom Objects.
Standard Objects include objects such as Account, Contact, and Opportunity - these objects are created automatically when you set up your organization.
Custom Objects are objects that you create yourself to meet your specific needs. For example, Invoice, Suggestion, and so on.
Objects can be related to one another, and there are two key relationship types whose behavior can differ depending on the use case.
Lookup is a relationship type that creates a weak connection between your objects. It is useful when your objects need to be related but can still exist independently of one another.
When the parent record is deleted, the behavior of the related Lookup record depends on the relationship configuration. Salesforce can clear the relationship field or prevent the deletion of the parent record in supported configurations.
Master-Detail is a strong relationship in which the parent controls the child. The child cannot exist independently of its parent and inherits the parent’s ownership and sharing settings. The relationship field is required, and deleting the parent also deletes all of its related child records. Roll-Up Summary fields are available for Master-Detail relationships.
Many-to-many relationships can be implemented using a junction object. A junction object typically connects two objects through two Master-Detail relationships, allowing multiple records on each side to be related.
Formulas & Validations
Formula Fields calculate values on the fly. They aren't stored in the database. They do not take up any space but always return the current value.
Validation Rules - in simple terms, this is a tool that ensures the accuracy of the data being entered. It does not display a value. Instead, it checks for compliance with certain conditions. If the validation condition is met, Salesforce prevents the record from being saved and displays an error message configured by the administrator. The message can explain how to correct the issue, depending on how it is written.
Salesforce Flow
Salesforce Flow is the platform’s primary low-code automation tool. The most common Flow types include:
- Record-Triggered Flow – runs when a record is created, updated, or deleted, depending on the trigger settings.
- Schedule-Triggered Flow – runs on a schedule that you define.
- Screen Flow – guides users through an interactive sequence of steps.
- Autolaunched Flow – a background flow that runs without user intervention and can be triggered from another flow, via Apex, or via the REST API.
- Platform Event-Triggered Flow – runs when a specified platform event is received.
- Flow Orchestration – coordinates multiple steps, actions, and participants to support complex business processes.
Flow can handle most routine automation tasks. However, when requirements or logic become too complex, developers turn to code, such as Apex.
Security Architecture & Data Management
Security Basics
Security in Salesforce is represented as a pyramid consisting of four levels:
- Organization
- Object
- Field
- Record
Each user has one profile that defines baseline permissions and settings. Profiles control access to objects and fields, along with certain system-level settings such as login hours and IP ranges. Organization-level settings and record-level security are separate parts of the overall Salesforce security model.
CRUD (Create, Read, Update, Delete) and FLS (Field-Level Security) represent two different levels of access. CRUD governs access to an object, while FLS governs access to a specific field.
Key rule: profiles grant the minimum. Permission Sets expand rights - they never restrict them.
Record-Level Security
Source: Salesforce Trailhead
Record-Level Security does not define which objects and fields a user can access; instead, it defines which records the user can access.
Salesforce uses several mechanisms to manage record access. Four core mechanisms include Organization-Wide Defaults, Role Hierarchy, Sharing Rules, and Manual Sharing. Other mechanisms, such as Restriction Rules, Teams, Territory Management, and Apex Managed Sharing, can also affect record access.
- Organization-Wide Defaults (OWD) define the starting level of access to records for users who do not own them.
- Role Hierarchy can extend record visibility to users higher in the hierarchy, depending on the object's configuration and sharing settings.
- Sharing Rules provide additional record access to selected users or groups when the default sharing settings are not sufficient.
- Manual Sharing allows authorized users to share individual records with specific users or groups when additional access is needed.
Restriction Rules can further limit which records a user can access, even when access would otherwise be granted through other sharing mechanisms.
These mechanisms work together to define record access. Some mechanisms grant additional access, while others, such as Restriction Rules, can limit the records available to a user.
Permission Set Groups
A user can have only one profile, but you can assign multiple permission sets to that user.
When configuring access, you’ll need to create many permission sets, but if you assign permission sets to each user individually, it’s easy to get confused - that’s why permission set groups exist.
A Permission Set Group is a tool that combines several individual permission sets into a single package for convenient assignment to users.
However, it often happens that a single permission set is suitable for several departments at once, but a specific department needs to have a couple of extra permissions revoked. To avoid having to create a new group from scratch for them or modify existing permission sets, a Muting Permission Set is used within this group. It allows you to selectively mute specific permissions only for members of this group, without affecting the original permission sets in any way.
Data Management
Once your settings are configured, you’ll need a way to upload, update, and clean your data. Salesforce offers two tools for this: Data Loader and the Data Import Wizard.
Data Loader is a desktop app. It handles up to 150 million records and works with any object.
Data Import Wizard is available within the Salesforce UI and supports importing up to 50,000 records at a time into selected standard and custom objects. For standard objects, it supports Accounts, Contacts, Leads, Solutions, and Campaign Members. It is designed for simpler import scenarios, while Data Loader is more suitable for larger data volumes and complex import operations.
Headless 360 Platform Development Basics
In April 2026, Salesforce introduced Headless 360, but it’s important to understand that this is not a new product, but rather an architectural innovation. Salesforce has offered REST and SOAP APIs for years, but many capabilities still required the user interface. Now, every platform capability is available via APIs, MCP tools, and the command line interface (CLI).
It's important to know that AI agents don't interact with the system like humans do by clicking buttons or typing. Instead, they make API calls. Headless 360 offers MCP tools and preconfigured coding skills designed for coding agents such as Claude Code, Cursor, and Codex. These skills are focused on supporting development workflows rather than serving as general-purpose capabilities for all AI agents.
Security remains an essential part of agent-driven development. Agents operate on behalf of an authenticated user and respect the permissions and sharing rules available to that user. This means that least-privilege access is essential, since excessive permissions granted to a user may also be available to an agent operating as that user.
Conclusion
Salesforce is more than a CRM - it is a platform where data, security, automation, and AI work together.
In this module, we explored the fundamentals of data modeling, including objects, relationships, formulas, and validation rules. We also looked at Flow as the primary low-code automation tool and learned how security controls access at the organization, object, field, and record levels.
Finally, we covered permission management, data management tools, and the evolution toward Headless 360 and AI agents.
The key takeaway is simple: understanding data modeling, security, automation, and AI is essential for building scalable and secure Salesforce solutions.
