Trigger: apex code which perform operation before and after DML operation( 6).

Account : formula, validation rule, relationship,workflow rule.process builder,sharing and

ponit and click--> out of box technique

execution flow of trigger/salesforce/apex : this can not be controlled by programmer.

1.fetch all data from database.(DML)

2.system validation.

3.before triggers

4.custom validation--validation rule,formula.

5.after triggers.

6.workflow rule and process builder(any changes occur then before and after trigger execute
once again).

7.rollup summary

8.sharing and security

9. commit changes in database(dml operation).

10.post commit operation(sending email alert).

context variable in triggers:

false ,when your current context of vf page.

isInsert== true ,if tigger is fired due to insert operation.

isUpdate == true ,if tigger is fired due to update operation.

isDelete == true ,if tigger is fired due to delete operation.

isUndelete == true ,if tigger is fired due to undelete operation(when resord is envoked from
recycle bin) .

isBefore== beford record save

isAfter -== after rtecord save

new ==Returns a list of the new versions of the sObject records.

This sObject list is only available in insert, update, and undelete triggers, and the records can only be
modified in before triggers.

newMap ==A map of IDs to the new versions of the sObject records.

This map is only available in before update, after insert, after update, and after undelete triggers.

old== Returns a list of the old versions of the sObject records.

This sObject list is only available in update and delete triggers.

oldMap ==A map of IDs to the old versions of the sObject records.

This map is only available in update and delete triggers.

operationType == Returns an enum of type System.TriggerOperation corresponding to the current

Possible values of the System.TriggerOperation enum are: BEFORE_INSERT, BEFORE_UPDATE,

size== The total number of records in a trigger invocation, both old and new.
 event in trigger: before/after DML

before insert : data insert

before update: reinstall some data in record

before delete (before undelete operation is possible??)

after insert: record save

after update

after delete

after undlete.:

trigger.old difference trigger.new

trigger.old and trigger.oldMap

trigger.new and trigger.newmap.

trigger : apex code which executes before and after dml operations.

types of trigger : 2types

1.before:before trigger is used to perform logic on the same obhect or only one object.

eg account ,contact.case, oppoertunity (single)

2. after: are used to perform logic on child to parent or parent to child object if any relationship
is there in between two objcts.(2 object)

account-contact, account-opportunity, hiring manager-position.

1) One Trigger Per Object

A single Apex Trigger is all you need for one particular object. If you develop multiple Triggers for a
single object, you have no way of controlling the order of execution if those Triggers can run in the same
contexts

2) Logic-less Triggers

If you write methods in your Triggers, those can’t be exposed for test purposes. You also can’t expose
logic to be re-used anywhere else in your org.(helper and handler classes).

3) Context-Specific Handler Methods

Create context-specific handler methods in Trigger handlers .

4) Bulkify your Code

Bulkifying Apex code refers to the concept of making sure the code properly handles more than one
record at a time.

5) Avoid SOQL Queries or DML statements inside FOR Loops ()100 200

An individual Apex request gets a maximum of 100 SOQL queries before exceeding that governor limit.
So if this trigger is invoked by a batch of more than 100 Account records, the governor limit will throw a
runtime exception

6) Using Collections, Streamlining Queries, and Efficient For Loops

It is important to use Apex Collections to efficiently query data and store the data in memory. A
combination of using collections and streamlining SOQL queries can substantially help writing efficient
Apex code and avoid governor limits

7) Querying Large Data Sets

The total number of records that can be returned by SOQL queries in a request is 50,000. If returning a
large set of queries causes you to exceed your heap limit, then a SOQL query for loop must be used
instead. It can process multiple batches of records through the use of internal calls to query and
queryMore
8) Use @future Appropriately

It is critical to write your Apex code to efficiently handle bulk or many records at a time. This is also true
for asynchronous Apex methods (those annotated with the @future keyword). The differences between
synchronous and asynchronous Apex can be found

9) Avoid Hardcoding IDs :

When deploying Apex code between sandbox and production environments, or installing Force.com
AppExchange packages, it is essential to avoid hardcoding IDs in the Apex code. By doing so, if the
record IDs change between environments, the logic can dynamically identify the proper data to operate
against and not fail.

10. naming convention :

account :oberct--- upadtetiggr

accounttriggger:

Few more Best Practices for Triggers

There should only be one trigger for each object.

Avoid complex logic in triggers. To simplify testing and resuse, triggers should delegate to Apex classes
which contain the actual execution logic. See Mike Leach's excellent trigger template for more info.

Bulkify any "helper" classes and/or methods.

Trigers should be "bulkified" and be able to process up to 200 records for each call.

Execute DML statements using collections instead of individual records per DML statement.

Use Collections in SOQL "WHERE" clauses to retrieve all records back in single query

Use a consistent naming convention including the object name (e.g., AccountTrigger)

dev (sandbox:4)--test-- uat-- preprod-- production(deploy)