Apex Code: On-Demand Programming with Permissions

Salesforces Apex code is a strongly typed object-oriented programming language that empowers developers to execute flow and transaction statements on the famous Force.com platform server while simultaneously running calls to the Force.com API.

The syntax looks a lot like Java and acts a lot like database stored procedures. This technology enables developers to add business logic to most system events like Visualforce pages, button clicks, and related record updates.

The Apex code can be initiated by triggers on objects and web service requests. What’s more, this on-demand platform offers a complete set of tools and features to build business-centric applications.

These include data objects and models to manage data, workflow engines to help manage the collaboration of that data, SOAP API for programmatic access and integration, and a user interface model that helps with forms and other interactions.

Apex code essentially enables programmers to write code that runs on salesforce.com servers. This allows the creation of features and applications that can be developed and deployed on-demand.

However, permissions are the primary element of both Apex programming and declarative development. For the most part, Apex classes are run in system context without considering sharing rules, privileges, and levels of access to the fields.

As a result, it ensures that the web services and triggers have access to all entries of the organization (and more often than not, this can be a good thing). But when it comes to maintaining the confidentiality of the data for users who don’t have permission to access it, you can create an Apex class to consider sharing rules, privileges, and levels of access to the fields by each user.

This approach can have an impact of the following:

DML expressions
SOSL
SOQL

If you’re using declarative development, you are enabled to easily share entries. But sometimes this should be executed dynamically following the specific business logic. Apex takes this into consideration and has a specific mechanism known as Apex Managed Sharing to help make this process much easier.

If you’re just venturing into Apex Code development, you’re going to have some questions. In this post, I will cover some of the basics.

What are the differences between System Mode and User Mode?

System Mode basically runs Apex code while ignoring the user’s permissions and privileges. In the System Mode, Apex code will have access to all the fields and objects while sharing rules and field security aren’t applied to the current user.

All Apex code runs on System Mode and this ensures that the code won’t fail to run because of hidden objects for the user or hidden fields. The only exceptions here are anonymous blocks like standard controllers and developer consoles.

In the User Mode, the code will be executed taking the privileges of the user into consideration. On the Salesforce platform, only Anonymous Apex and standard controllers can be executed in User Mode. In other words, it only runs Apex code by respecting the user’s permissions and sharing of records.

What are the differences between With Sharing and Without Sharing?

Apex has its own set of keywords like “With Sharing” and “Without Sharing.” These can be used for classes that don’t impact field-level security.

“Without Sharing” means that the sharing rules won’t be applied for the current user. It’s only used when a user doesn’t have an access to the entry but still needs to edit it. “With Sharing” means sharing will be applied for the current user.

These keywords only feature the sharing rules and don’t include any field-level security or CRUD. “With Sharing” should also be used when you want to refresh the data on the user’s part. It’s also used quite often for pages that have to work while taking sharing rules into consideration.

For example, if the page controller for editing an Opportunity is to be declared as “With Sharing,” it will ensure that the users can’t edit the Opportunity they can’t access. On the other hand, “Without Sharing” can be used when you need to see the entries that can’t be accessed.

For example, the users won’t be able to see other users’ Leads, however, the system should be enabled to make the potential duplicates and send a notification about someone duplicating Leads.

At this juncture, it’s important to eliminate the myth that Apex Triggers always run on the System Mode irrespective of sharing settings. This means it is the Apex Trigger that is calling a class declared “With Sharing” where all the context user rules will apply during trigger execution.

If the triggers are expecting to query all the records with the code running under the context “With Sharing”, then the user’s profile will also be taken into consideration.

I have only touched the tip of the iceberg in this post, so if you want to learn more, please let us know in the Comments section below.