1. Loads the original record from the database or initializes the record for an upsert statement.
2. Loads the new record field values from the request and overwrites the old values. If the request came from a standard UI edit page, Salesforce runs system validation to check the record for: • Compliance with layout-specific rules • Required values at the layout level and field-definition level • Valid field formats • Maximum field length Salesforce does not perform system validation in this step when the request comes from other sources, such as an Apex application or a Web Services API call.
3. Executes all before triggers.
4. Runs most system validation steps again, such as verifying that all required fields have a non-null value, and runs any user-defined validation rules. The only system validation that Salesforce does not run a second time (when the request comes from a standard UI edit page) is the enforcement of layout-specific rules.
5. Saves the record to the database, but does not commit yet.
6. Executes all after triggers.
7. Executes assignment rules.
8. Executes auto-response rules.
9. Executes workflow rules.
10. If there are workflow field updates, updates the record again.
11. If the record was updated with workflow field updates, fires before and after triggers one more time (and only one more time).
12. Executes escalation rules.
13. If the record contains a roll-up summary field or is part of a cross-object workflow, performs calculations and updates the roll-up summary field in the parent record.
14. Commits all DML operations to the database.
15. Executes post-commit logic, such as sending email.
Order of exection:
1. Loads the original record from the database or initializes the record for an upsert statement.
2. Loads the new record field values from the request and overwrites the old values. If the request came from a standard UI
edit page, Salesforce runs system validation to check the record for:
• Compliance with layout-specific rules
• Required values at the layout level and field-definition level
• Valid field formats
• Maximum field length
Salesforce does not perform system validation in this step when the request comes from other sources, such as an Apex
application or a Web Services API call.
3. Executes all before triggers.
4. Runs most system validation steps again, such as verifying that all required fields have a non-null value, and runs any
user-defined validation rules. The only system validation that Salesforce does not run a second time (when the request
comes from a standard UI edit page) is the enforcement of layout-specific rules.
5. Saves the record to the database, but does not commit yet.
6. Executes all after triggers.
7. Executes assignment rules.
8. Executes auto-response rules.
9. Executes workflow rules.
10. If there are workflow field updates, updates the record again.
11. If the record was updated with workflow field updates, fires before and after triggers one more time (and only one
more time).
12. Executes escalation rules.
13. If the record contains a roll-up summary field or is part of a cross-object workflow, performs calculations and updates the
roll-up summary field in the parent record.
14. Commits all DML operations to the database.
15. Executes post-commit logic, such as sending email.
the above is from the APEX Documentation (search for "Order of execution")
for future reference:
http://www.salesforce.com/us/developer/docs/apexcode/index.htm