Start tracking your progress
Trailhead Home
Trailhead Home

Learn How Authorization Works in Apps

Learning Objectives

After completing this unit, you’ll be able to:

  • Differentiate between the main ways you can protect access to data in your org.
  • Understand when the platform automatically enforces authorization settings.

What Is Authorization?

Access to online data is generally restricted to only those who are identified, authenticated, and authorized. In this module, we focus on authorization, which determines who is able to access which resources.

To understand this concept, think about the data in your own Salesforce org. For example, let’s assume you store information about your users. Some of this information is sensitive, like salary information or Social Security numbers. Authorization lets you specify that only HR or Payroll has access to those fields for everyone in the org, while regular users can see only their own data. That’s the power of authorization!

Authorization in Salesforce: A Primer

Configuring authorization and restricting access to data on the Salesforce platform is easy. By simply assigning a certain profile or permission set to a user, an admin can define what level of access the user has to the data stored in the org. 

This is accomplished in three main ways:

  • Create, read, update, and delete (CRUD) settings
    • Determine which objects a user can create, read, update, and delete
  • Field level security (FLS) settings
    • Determine which fields a user can read and edit
  • Sharing Rules
    • Determine which records are visible to users

The easiest way to visualize these three concepts is to think about a spreadsheet.

Spreadsheet illustrating CRUD as a tab, FLS as a column, and sharing as a row

  • CRUD limits which tabs (or objects) a user can access.
  • FLS limits which columns (or fields on an object) a user can access.
  • Sharing limits which rows (or object records) a user can access.

To learn more about how these settings work and how to configure them as an admin, check out the Data Security module.

Developers and Authorization

So admins configure authorization settings via the profile and permission sets in Setup. They take care of it all, right?

Wrong! As a developer, you too have a role to play in enforcing authorization controls. The admin sets the rules, but it’s your job to ensure that your application properly respects them.

How the Salesforce Platform Enforces Authorization

In most cases the platform automatically enforces admin-configured authorization settings, so your job is easy. However, because the platform is flexible, there are certain cases where developers can bypass authorization settings. 

To understand why and where this happens, you need to understand the two execution contexts that a app runs in: user and system. 

User Context

User context is the default context that you see when you’re interacting with the basic UI in Salesforce. In user context, the current user’s permissions, field-level security, and sharing rules are taken into account as you browse the UI or execute code.

The platform runs in user context when:

  • A user browses the application via the standard Salesforce-provided UI
  • A user views a Visualforce page that uses a standard controller
  • A user views a Visualforce page that references objects with standard object notation
  • The platform executes Anonymous Apex via console or API calls
  • An application on the platform makes a standard API call

This mode is ideal for developers because it enforces all admin configured authorization settings by default. However, user context can limit what data your custom code can interact with. 

System Context

To support a wide range of features and richer UI experience, the platform can also execute in system context. In this mode, the platform does not take into account the current user's permissions, field-level security, and sharing rules during code execution. 

Think of this as code executing with elevated privileges, running as root or as an admin. In this mode, applications have access to all objects and fields that are available in the org, including encrypted fields.

The platform executes code in system context in:

  • Apex Classes (including web services)
  • Apex Triggers
  • Apex web services called from the API

What Is the Purpose of Multiple Contexts?

From a security perspective, user context is preferable because user access controls are maintained throughout the transaction. This is why standard pages and Visualforce pages built on standard controllers run in user context. But the restrictions of user context aren’t always appropriate for custom business processes and applications. 

Custom Apex and Visualforce applications often require permissions beyond the scope of user's access. System context provides the necessary flexibility for these applications. As a developer, you have to use this flexibility thoughtfully and carefully. With great power comes great responsibility! 

Learn Authorization with the Kingdom Management App

To illustrate this concept, we use a sample app called Kingdom Management. In this module, you assume the role of the lead Apex developer for the app, which lets castle-dwelling users track their inventory. As this app processes potentially sensitive data about the kingdoms in the land, make sure that you’re properly enforcing authorization checks throughout, so no data is exposed to, or modified by, unauthorized users. 



If you’ve completed other modules in this trail, it’s possible you already signed up for this org in a previous module. However, if you signed up for the Kingdom Management org before March 27, 2017, you have to sign up again. You need a fresh copy of the org to get the latest content. 

To get set up in the Kingdom Management developer org, you need to sign up.

  1. Go to the custom signup page for the Kingdom Management developer org:
  2. Fill out the form using an active email address and click Sign Me Up.
    Signup page for the Kingdom Management Org

  3. Check your email for an activation request.
  4. Click the link in the email, and complete your registration by setting a new password and challenge question.

After you have your Kingdom Management developer username, you are ready to start learning how to defend your data from invaders.



The code in the Kingdom Management application is intentionally filled with certain kinds of vulnerabilities. In the developer org, these vulnerabilities are benign, but they can pose more serious problems if replicated to a production Salesforce environment. Use the Kingdom Management application for educational purposes only.

Navigating the Kingdom Management Developer Org

Throughout this module and the other modules in this trail, we refer to the Kingdom Management application and the demos and challenges contained therein. Below are the various features for navigating the developer org.

  • On the upper right side, the application picker contains apps that refer to various topics covered by the modules and units. Multiple units may refer to a single application as long as they share the same topic.
  • The tab bar for each app contains tabs specific to demos and challenges. The content refers to each of these demos and challenges by name.
  • Inside each tab, the Visualforce page has a Demo section that contains the contents of the issue being demonstrated.
  • Inside each tab, the Visualforce page has a Code Links section that contains quick links to the pieces of code relevant to the demo or challenge. Clicking the link takes you to the Visualforce page, Apex controller, or other items associated with your demo or challenge.

We occasionally make updates to this org and the underlying apps. To see if you’re using the latest and greatest copy, check out the Overview tab in each of the custom apps.

Screenshot of the Overview tab in the Kingdom Management developer org

If you see that your org is out of date, check out the release notes and sign up for a new version of the org.