Learn Salesforce Certification with Free Lessons & Tips

Hello Subash,

My name is Devika. I have total of 4.5 Yrs of Experience as Salesforce Consultant. I have worked on Several Projects. Its good if you want to start your career in Salesforce. Its very high in Demand now a days. 

Currently I am working as Freelancer as Salesforce Trainer and Training 5 Candidates Online. If you are interested you can revert me with your email ID on this.

Thanks

Imagine you have two users. Both are in the same profile, which allows them to Create, Edit object XYZ. But these two users are in different parts of the role hierarchy.

If User A Creates an XYZ, can user B edit it? The answer is only if the record is shared with him. If the Org Wide Default is Private then he will not even be able to see the record that User A has created (unless it is explicitly shared with him). He can still create his own XYZ records and edit those. Likewise, if the Org Wide Default is public read only, User B could see it, but not edit it despite what his profile allows. He can edit only his own records or those shared with him.

Sharing also works up the role hierarchy. So User A's boss can see the XYZ record that User A created. If his profile allows, he can edit it, but his profile may not.

You can think of the profile as "What can a user do with the XYZ object" and the sharing as "Which particular XYZ records can he or she do it with"

If OWD is Public Read / Write but the profile does not have access to Read or to Edit then you cannot Read or Edit.

If OWD is Public Read / Write on object XYZ and profile has Read permission but not Edit, then the user with that profile can only Read XYZ (all of them).

If a user doesn't even have Read access to object XYZ then they cannot see any object XYZ regardless of the Org Wide Default.

Not correct : The owner who is higher on the role hierarchy has shared access to all the XYZ that his subordinates own. However, if the higher user has a profile which doesn't include read or edit then he cannot read or edit those records.

• By default all the variables and methods are non-static.

• Scope of the non-static variables or methods is within the scope of the same object.

• We can declare variables and methods as static by using static keyword.

• Scope of the static variables and methods is throughout the transaction.

• Static variables and methods, we can directly call with class name (we cannot access static variables and methods with object name).

//Map holds key and value pair.

//Syntax: Map mapName = new Map();

/*Map countryISTCodeMap = new Map();

countryISTCodeMap.put('India','91');

countryISTCodeMap.put('USA','001');

countryISTCodeMap.put('India','911');//replaces old value with new value.*/

Map countryISTCodeMap = new Map{'India'=>'91','USA'=>'001', 'India'=>'911'};

system.debug('countryISTCodeMap result: '+countryISTCodeMap+' with size '+countryISTCodeMap.size());

system.debug('countryISTCodeMap keys: '+countryISTCodeMap.keyset());

system.debug('countryISTCodeMap values: '+countryISTCodeMap.values());

system.debug('countryISTCodeMap search: '+countryISTCodeMap.containsKey('India'));

system.debug('countryISTCodeMap fetching value based on key: '+countryISTCodeMap.get('India'));

//map keys are case-sensitive.

keyset(): To fetch only keys from the map.

values(): To fetch only values from the map.

containsKey(value): To search a key from the map.

get(key): By supplying the key we can fetch the value.

put(key,value): To add key and value in a map.

1. SOQL: Salesforce Object Query Language

• SOQL: Salesforce Object Query Language

• SOQL Purpose: To fetch info. from an object and related objects.
• We can write query on one object while querying on those objects we can fetch the child object info. or parent object info. (we cannot capture un related objects info.)
• SOQL queries per transaction: 100.
• SOQL query rows returned: 50000.

2. SOSL: Salesforce Object Search Language

• SOSL: Salesforce Object Search Language.
• SOSL Purpose:We can search for a value in multiple objects (no need of any relationship).
• Results of SOSL query can be stored in List of List.
• SOSL queries per transaction: 20.
• SOSL query rows returned: 2000.

insert/update

Database.insert/Database.update

Assume that you are inserting 100 records. If any one of the record fail due to error then entire operation will fail. None of the records will be saved into the database. with insert/update if we use try-catch then we can capture only one error which will cause to stop the operation.

Assume that you are inserting 100 records. If any one of the record fail due to error then it will perform partial operation (valid records will be inserted/updated) if we use Database.insert(list,false)/ Database.update(list,false).

.with Database.insert/Database.update we can capture all the errors by saving result in Database.saveResult[].

1. Before Triggers:

To perform the validations we should use before triggers.

If you are updating any field on the same object on which you are writing the trigger and no need to explicitly include the DML statemetns (already due to DML operation only trigger fire and it is still in progress at this point of time.)

2. After Triggers:

If you are dealing with relationship records and if you need record id in these situations we should use after trigger (in before insert record doesn't contain the record id).

3. For the same event if there are multiple triggers on the object, how to control the order of execution?

We cannot control the order of execution in this situation. It is recommended to have only one trigger per one object.

Note: We can keep the logic of the apex trigger in an apex class and can invoke from that class.

4. What are the recursive triggers and how to avoid?

If we perform update operation on the record in after update event logic recursive triggers will arise.

Using static boolean variable in an apex class (we should not keep static boolean variable inside of the trigger) we can avoid recursive triggers.

If we perform DML operation on standard/custom object and global objects(User, UserRole, Group, GroupMember, Permission Set, etc...) in same transaction this error will come.

To avoid this error, we should perform DML operation on standard/custom object records in a different transaction.

In general all the apex classes and apex triggers execute synchronously (execute immediately).

If we perform DML operation on standard/custom object records asynchronously (execute in future context), we can avoid MIXED-DML-OPERATION error.

To execute logic asynchronously keep the logic in an apex method (in a separate apex class, not in same apex trigger) which is decorated with @future annotation.

See the below example:

Note: To analyse the code copy it and paste it in notepad for the convenience.

 public class TriggerUtility {

  /*                    

  1. Following future method execute asynchronously (whenever server is free it will execute in future context).

  2. We should not declare @future method in Apex Trigger.

  3. @future method should be always static.

  4. @future method accepts only primitive data types (Integer, String, Boolean, Date, etc...) as parameters and it won't accept

  non-primitive data types (sObject,Custom Objects and standard Objects etc.. ) as parameters.

  5. @future method should not contain return type. Always it should be void.

  6. From an apex trigger we can make only make asynchronous call outs. To make call out we should include "callout = true" beside the future @annotation.

  7. We cannot perform synchronous call outs from Apex Trigger.

  */

  //Below is the example for the future method -

  @future(callout = true)

  public static void processAsync(primitive parameters) {

   //Logic to insert/update the standard/custom object.

  }

 }

To schedule the batch class in minutes/hours, in the finish method we should use System.schedule method which will take 3 parameters Job Name, Chrone Expression and schedulable class instance name respectively.

   /*** Scheduling in minutes or hours ***/

 //Create object for schedulable class

 SchedulableUsage su = new SchedulableUsage();

 //Preparing chron_exp

 Datetime sysTime = System.now();

 sysTime = sysTime.addminutes(6);

 String chron_exp = '' + sysTime.second() + ' ' + sysTime.minute() + ' ' +

 sysTime.hour() + ' ' + sysTime.day() + ' ' + sysTime.month() + ' ? ' + sysTime.year();           

 System.schedule('Dep Update'+sysTime.getTime(),chron_exp, su);