Back to the Basics: Salesforce Deployment, Security & Data Relationships

Salesforce is a powerful platform, but its flexibility can also make it complex. As organizations add users, customize objects, integrate applications, and build more sophisticated processes, some of the fundamentals that support the entire platform can become easy to overlook.

For Salesforce administrators, understanding these fundamentals is important because many everyday challenges ultimately come back to a few core concepts: how changes are deployed, how access is controlled, and how data is structured. This blog covers some of the core concepts that form the foundation of Salesforce administration.

Deployment and Installation

Moving configuration between Salesforce environments is a common administrative task. Salesforce provides several ways to distribute metadata and applications, and choosing the right approach depends on what you are deploying and how frequently you need to manage changes.

Change Sets

Change Sets provide a point-and-click approach for moving customizations between related Salesforce orgs, such as a Sandbox and Production. They are particularly useful for smaller administrative deployments where a straightforward, UI-based process is appropriate. However, managing dependencies manually can become challenging as deployments become larger or more complex. Some important characteristics of Change Sets include:

• They support metadata and setup components, not data.
• Validation can be performed before deployment.
• Development orgs do not support Change Sets.
• A deployment connection must exist between the related orgs.
• Inbound changes must be allowed.
• If a deployment fails, the transaction is rolled back.
• Once successfully deployed, a Change Set cannot simply be reverted.
• Change Sets can be used between supported related orgs, such as Sandbox and Production.

For larger development teams and more sophisticated release processes, metadata-based deployment and version control provide greater flexibility.

Metadata Files

Salesforce metadata represents the configuration of an org. This includes components such as custom fields, page layouts, Apex classes, and other configuration elements. Working directly with metadata through tools such as Visual Studio Code and Salesforce CLI is an important part of modern Salesforce development and DevOps.

Metadata can also be stored in version-control systems such as Git. This allows teams to track configuration changes, collaborate on development, compare versions, and create more controlled deployment processes.

Managed Packages

Managed Packages are primarily used by AppExchange partners and other providers to distribute applications and solutions. The underlying code and packaged components are protected, meaning subscribers cannot freely view or modify the packaged code.

The provider manages the solution and can release updates, fixes, and new features. This makes managed packages particularly useful when an organization wants to install a third-party application while maintaining a controlled upgrade path.

Unmanaged Packages

Unmanaged Packages are generally used to distribute open-source code, sample applications, or reusable building blocks. Unlike managed packages, their components become editable after installation. However, they are not upgradeable in the same way as managed packages.

Once an unmanaged package is installed, there is no ongoing managed relationship with the original source. Any future changes or updates therefore need to be managed manually.

Understanding Record-Level Security

One of the most important parts of Salesforce administration is understanding who can access which records. Record-level security determines which specific records a user can see or edit. Salesforce generally uses a layered, additive approach to sharing. Administrators establish a baseline level of access and then use additional mechanisms to open access where required.

Org-Wide Defaults

Org-Wide Defaults, or OWDs, establish the baseline level of record access for an object. Common settings include:

• Private
• Public Read Only
• Public Read/Write

The OWD setting establishes the starting point for record access. Other mechanisms can then provide additional access. For example, if an object is Private, users may only have access to records they own unless another sharing mechanism grants them access.

Role Hierarchy

The Role Hierarchy can open up record access vertically within an organization. Users higher in the hierarchy can generally gain access to records owned by or shared with users below them, depending on the object’s sharing configuration. The important distinction is that Role Hierarchy is primarily about hierarchical access, rather than simply defining what a user can do with an object.

Sharing Rules

Sharing Rules provide additional access beyond the baseline established by OWDs and the Role Hierarchy. They can be based on:

• Record ownership
• Specific field values or criteria

Access can be granted to groups such as Public Groups, Roles, or Territories. Sharing Rules are particularly useful when users who are not part of the same management hierarchy still need access to the same records.

Manual Sharing

Manual Sharing allows access to be granted to an individual record. It is useful when an unusual or one-off situation requires a user or group to access a particular record without creating a broader sharing rule that would affect many records.

Team Sharing

Team Sharing provides a structured approach to collaborating on records. Examples include Account Teams, Opportunity Teams, and Case Teams. Team members can be given defined roles and access levels, such as Read or Read/Write. This is useful when multiple users regularly collaborate on the same records.

Restriction Rules

Restriction Rules work differently from most other sharing mechanisms. While sharing mechanisms generally grant access, Restriction Rules can restrict access. They allow administrators to filter out records that users should not see, even when other security settings might otherwise give them access. This makes Restriction Rules particularly useful for sensitive data.

Scoping Rules

Scoping Rules are intended primarily to reduce the amount of information presented to users. They can filter the records users see in places such as list views, searches, and reports. Unlike Restriction Rules, Scoping Rules are not intended to provide strict record-level security. They help users focus on relevant records without necessarily removing their underlying access.

Manager Groups

Manager Groups provide another way to share records with users based on management relationships. They can be used to share records with a user’s direct or indirect managers or reports without requiring administrators to create complicated sharing structures.

The Salesforce Security Model: Object vs. Record Access

A common source of confusion for Salesforce administrators is the difference between object-level and record-level security. A simple way to remember the distinction is:

Object-level security determines what a user can do. Record-level security determines which records they can access. For example, a user might have Read access to the Opportunity object but only be able to see certain Opportunity records because of the organization’s record-sharing configuration.

Profiles

Profiles provide a baseline set of permissions and settings for users. They can define fundamental capabilities such as object permissions, system permissions, and other user settings. Salesforce best practices increasingly favor keeping profiles relatively minimal and using Permission Sets to provide additional access where appropriate.

Permission Sets and Permission Set Groups

Permission Sets provide an additive way to grant users additional permissions without modifying their profiles. Instead of creating multiple profiles for small differences in access, administrators can use Permission Sets to grant specific permissions to selected users. Permission Set Groups allow administrators to bundle multiple Permission Sets together, making access easier to manage at scale.

Custom Permissions

Custom Permissions provide another layer of flexibility. They can be used to control access to specific applications, processes, Flows, Apex processes, or user-interface functionality. Rather than granting access to an entire object, a Custom Permission can help determine whether a particular user should be able to use a specific feature.

A Simple View of the Salesforce Security Layers

The security model becomes easier to understand when the different layers are viewed together.

Understanding these layers is critical when troubleshooting access issues. If a user cannot access something, the first question should be whether the problem is related to the object, field, or record.

Data Relationships

Salesforce data relationships determine how records connect to one another. Choosing the appropriate relationship type affects security, ownership, deletion behavior, and how data can be reported.

Lookup Relationships

A Lookup Relationship creates a relatively loose connection between two objects. The child record references the parent, but the two objects generally retain independent ownership and security settings. Deleting the parent does not automatically delete the child in a standard Lookup Relationship. Lookup relationships can also use Lookup Filters to restrict which records users can select.

Master-Detail Relationships

A Master-Detail Relationship creates a much tighter connection between parent and child records. The detail record depends on the master and inherits important security and sharing characteristics from it. If the master record is deleted, its associated detail records are also deleted. Master-Detail relationships are also required for Roll-Up Summary fields. Other characteristics include:

• Reparenting can be enabled where supported.
• Detail records inherit relevant security settings from the master.
• The master relationship is required on the detail record.
• A custom object can have up to two Master-Detail relationships.
• A detail object is dependent on its master.

The key distinction is straightforward: Use Lookup when the relationship between records should remain relatively independent. Use Master-Detail when the child record is fundamentally dependent on its parent.

Hierarchical Lookup

Hierarchical Lookup is a special relationship available on the User object. It allows one user to be connected to another user and can be useful for representing management structures, approval relationships, and organizational charts.

Indirect and External Lookup Relationships

Indirect Lookup Relationships connect Salesforce objects to External Objects using an External ID rather than a standard Salesforce Record ID. External Lookup Relationships can connect External Objects to other External Objects or Salesforce objects. These relationship types are particularly relevant when Salesforce needs to work with data that is stored outside the platform.

Lookup Filters

Lookup Filters restrict the records that users can select in a lookup field. For example, an administrator could configure an Opportunity lookup so that users can only select Accounts marked as “Active.” This helps prevent incorrect relationships from being created in the first place.

Conclusion

Salesforce administration becomes easier when the platform’s foundational concepts are understood as connected pieces. Deployment determines how configuration moves between environments. Security determines what users can do and which records they can access. Relationships determine how data is structured and connected.

These fundamentals are not just certification topics. They are the building blocks administrators use every day to troubleshoot access problems, design scalable solutions, and maintain a reliable Salesforce org.

Frequently Asked Questions (FAQs)

1. What is the Salesforce security model?
   The Salesforce security model uses multiple layers to control access. Object permissions determine what users can do, while field-level and record-level security determine what information they can see or edit.
2. What is the difference between a Profile and a Permission Set?
   A Profile provides a user’s baseline permissions, while Permission Sets add additional permissions without requiring changes to the user’s Profile.
3. What is the difference between Lookup and Master-Detail?
   A Lookup Relationship creates a relatively independent connection between two records. A Master-Detail Relationship creates a dependent parent-child relationship in which the detail record inherits important characteristics from the master.
4. What are Restriction Rules used for?
   Restriction Rules limit the records users can access based on defined criteria. Unlike sharing rules, which grant access, Restriction Rules can restrict access.
5. Are Change Sets still useful?
   Yes. Change Sets remain useful for straightforward administrative deployments between related Salesforce environments, although metadata-based deployment and modern DevOps practices provide greater flexibility for complex development workflows.