Dynamic Apex to check CRUD and FLS

As explained here: http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_classes_keywords_sharing.htm Apex generally runs in system context except for "Execute Anonymous", so the current user's permissions, field-level security, and sharing rules aren’t taken into account during code execution. Because these rules aren't enforced, developers who use Apex must take care that they don't inadvertently expose sensitive data that would normally be hidden from users by user permissions, field-level security, or organization-wide defaults.

With Sharing / Without Sharing

System context provides the correct behavior for system-level operations such as triggers and Web services that need access to all data in an organization. However, you can also specify that particular Apex classes should enforce the sharing rules that apply to the current user by using the "With Sharing" and "Without Sharing" keywords.

public with sharing class sharingClass {   // Code here         }

Remember that if a class is not declared as either with or without sharing, the current sharing rules remain in effect. This means that if the class is called by a class that has sharing enforced, then sharing is enforced for the called class. Note: A user's permissions and field-level security are always ignored to ensure that Apex code can view all fields and objects in an organization. If particular fields or objects are hidden for a user, the code would fail to compile at runtime. But sometimes, it is required to Apex check if the current running user is allowed to perform the operation based on the other security settings (FLS, CRUD). You can easily check this using Dynamic Apex.

CRUD: Create / Read / Update / Delete permissions on an object.

To check object level permissions (CRUD), you want to use the methods in the Schema.DescribeSObjectResult class, specifically:

Useful methods in class: Schema.DescribeSObjectResult isCreateable() isAccessible() isUpdateable() isDeletable()

These methods are described here: http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_methods_system_sobject_describe.htm

FLS:Field Level Security permissions.

To check field level security permissions (FLS), you want to use the methods in the Schema.DescribeFieldResult class, specifically:

Useful methods in class: Schema.DescribeFieldResult isAccessible() isCreateable() isNillable() isUpdateable()

These methods are described here: http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_methods_system_fields_describe.htm

Sample Code

This sample code has two methods to check the CRUD permissions on the Account object and the FLS permissions on the Account.Industry field that are in placed for the user who is currently running your code.

public class demoDynamicApexMethods {     public void SObject_Information() {         Schema.DescribeSObjectResult drSObj = Schema.sObjectType.Account;         System.debug(drSObj.getChildRelationships());         System.debug(drSObj.getRecordTypeInfos());         System.debug(drSObj.getRecordTypeInfosByID());         System.debug(drSObj.getRecordTypeInfosByName());         System.debug(drSObj.isCreateable());         System.debug(drSObj.isAccessible());         System.debug(drSObj.isUpdateable());         System.debug(drSObj.isDeletable());         System.debug(drSObj.isFeedEnabled());     }     public void Field_Information() {         Schema.DescribeFieldResult drField = Account.Industry.getDescribe();         System.debug(drField.getLabel()); // Similar to VF tag: {!$SObjectType.Account.Fields.Name.Label}         System.debug(drField.getPicklistValues());         System.debug(drField.isAccessible());         System.debug(drField.isCreateable());         System.debug(drField.isNillable());         System.debug(drField.isUpdateable());     } }