Salesforce Apex Trigger

What Is Trigger?

Apex can be invoked through the use of triggers. A trigger is Apex code that executes before or after the following types of operations:

insert
update
delete
merge
upsert
undelete

Trigger and Recovered Records:

The after undelete trigger event only works with recovered records—that is, records that were deleted and then recovered from the Recycle Binthrough the undelete DML statement. These are also called undeleted records.

The after undelete trigger events only run on top-level objects. For example, if you delete an Account, an Opportunity may also be deleted. When you recover the Account from the Recycle Bin, the Opportunity is also recovered. If there is an after undelete trigger event associated with both the Account and the Opportunity, only the Account after undelete trigger event executes.

The after undelete trigger event only fires for the following objects:

Account
Asset
Campaign
Case
Contact
ContentDocument
Contract
Custom objects
Event
Lead
Opportunity
Product
Solution
Task

Merger Trigger:

Merge events do not fire their own trigger events. Instead, they fire delete and update events as follows:

Deletion of losing records: A single merge operation fires a single delete event for all records that are deleted in the merge. To determine which records were deleted as a result of a merge operation use the MasterRecordId field in Trigger.old. When a record is deleted after losing a merge operation, itsMasterRecordId field is set to the ID of the winning record. The MasterRecordId field is only set in after delete trigger events. If your application requires special handling for deleted records that occur as a result of a merge, you need to use the after delete trigger event.
Update of the winning record: A single merge operation fires a single update event for the winning record only. Any child records that are reparented as a result of the merge operation do not fire triggers.

For example, if two contacts are merged, only the delete and update contact triggers fire. No triggers for records related to the contacts, such as accounts or opportunities, fire.

The following is the order of events when a merge occurs:

The before delete trigger fires.
The system deletes the necessary records due to the merge, assigns new parent records to the child records, and sets the MasterRecordId field on the deleted records.
The after delete trigger fires.

The system does the specific updates required for the master record. Normal update triggers apply.

Trigger Context Variable:

Variable	Usage
`isExecuting`	Returns true if the current context for the Apex code is a trigger, not a Visualforce page, a Web service, or an `executeanonymous()` API call.
`isInsert`	Returns true if this trigger was fired due to an insert operation, from the Salesforce user interface, Apex, or the API.
`isUpdate`	Returns true if this trigger was fired due to an update operation, from the Salesforce user interface, Apex, or the API.
`isDelete`	Returns true if this trigger was fired due to a delete operation, from the Salesforce user interface, Apex, or the API.
`isBefore`	Returns true if this trigger was fired before any record was saved.
`isAfter`	Returns true if this trigger was fired after all records were saved.
`isUndelete`	Returns true if this trigger was fired after a record is recovered from the Recycle Bin (that is, after an undelete operation from the Salesforce user interface, Apex, or theAPI.)
`new`	Returns a list of the new versions of the sObject records. Note that this sObject list is only available in `insert` and `update` triggers, and the records can only be modified in `before` triggers.
`newMap`	A map of IDs to the new versions of the sObject records. Note that this map is only available in `before update`, `after insert`, and `after update` triggers.
`old`	Returns a list of the old versions of the sObject records. Note that this sObject list is only available in `update` and `delete` triggers.
`oldMap`	A map of IDs to the old versions of the sObject records. Note that this map is only available in `update` and `delete` triggers.
`size`	The total number of records in a trigger invocation, both old and new.

Example:

Trigger t on Account (after insert) {

for (Account a : Trigger.new) {

// Iterate over each sObject

}

// This single query finds every contact that is associated with any of the

// triggering accounts. Note that although Trigger.new is a collection of

// records, when used as a bind variable in a SOQL query, Apex automatically

// transforms the list of records into a list of corresponding Ids.

Contact[] cons = [SELECT LastName FROM Contact

WHERE AccountId IN :Trigger.new];

}

Be aware of the following considerations for trigger context variables:

trigger.new and trigger.old cannot be used in Apex DML operations.
You can use an object to change its own field values using trigger.new, but only in before triggers. In all after triggers, trigger.new is not saved, so a runtime exception is thrown.
trigger.old is always read-only.

You cannot delete trigger.new.

How to avoid Recursive trigger:

Example:
Suppose there is a scenario where in one trigger perform update operation, which results in invocation of second trigger and the update operation in second trigger acts as triggering criteria for trigger one.

Solution:

Class:

public class Utility
{
    public static boolean isFutureUpdate;
}

Trigger:

trigger updateSomething on Account (after insert, after update)
{

    /* This trigger performs its logic when the call is not from @future */
    if(Utility.isFutureUpdate != true)
    {

        Set<Id> idsToProcess = new Se<Id>();

        for(Account acct : trigger.new)
        {
            if(acct.NumberOfEmployees > 500)
            {
                idsToProcess.add(acct.Id);
            }
        }

        /* Sending Ids to @future method for processing */
        futureMethods.processLargeAccounts(idsToProcess);

    }
}

Class:

public class FutureMethods
{

    @future
    public static void processLargeAccounts(Set<Id> acctIDs)
    {

        List<Account> acctsToUpdate = new List<Account>();

        /* isFutureUpdate is set to true to avoid recursion */
        Utility.isFutureUpdate = true;

        update acctsToUpdate;
    }
}

Salesforce Sharing Rule

The terms “Record-Level Access” and “Sharing” are interlinked in Salesforce.com. Sharing enables record-level access control for all custom objects. Sharing can also be enabled for many standard objects such as (such as Account, Contact, Opportunity and Case).

Levels of Record Access

View, Edit, Transfer, Share, and Delete

Default Sharing Access

Default sharing access is set through organization-wide defaults (OWD).

Additional Record-Level Access Types

1. Force.com Managed Sharing

All implicit sharing added by Force.com managed sharing cannot be altered directly using the Salesforce user interface, SOAP, API, or Apex.

Record Ownership

Every record is owned by a user or a queue (in case of custom objects, cases, and leads). The record owner is automatically granted Full Access to the record. This enables them to access the record on all levels (view, edit, transfer, share, and delete).

Role Hierarchy

If “Role Hierarchy” is enabled, users above another users in the hierarchy can have the same level of access to records owned by or shared with users below. This behavior can be disabled for specific custom objects. Role hierarchy is not maintain with sharing records. Role hierarchy access is derived at runtime.

Sharing Rules

With sharing rules, an administrator can automatically grant users within a given group or role access to records owned by specific group of users.

2. User Managed Sharing, also known as “Manual Sharing”

User managed sharing allows the record owner or any user with Full Access to a record to share the record with a user or group of users. This is generally done by an end-user, for a single record. Only the record owner and users above the owner in the role hierarchy are granted Full Access to the record. It is not possible to grant other users Full Access. Users with the “Modify All” object-level permission for the given object or the “Modify All Data” permission can also manually share a record. User managed sharing is removed when the record owner changes or when the access granted in the sharing does not grant additional access beyond the object’s organization-wide sharing default access level.

3. Apex Managed Sharing

Apex managed sharing provides developers with the ability to support an application’s particular sharing requirements programmatically through Apex or the SOAP API. This type of sharing is similar to Force.com managed sharing. Only users with “Modify All Data

Types of Sharing in Salesforce

Salesforce has the following types of sharing:

1. Force.com Managed Sharing
Force.com managed sharing involves sharing access granted by Force.com based on record ownership, the role hierarchy, and sharing rules:

1.1 Record Ownership
Each record is owned by a user or optionally a queue for custom objects, cases and leads. The record owner is automatically granted Full Access, allowing them to view, edit, transfer, share, and delete the record.

1.2 Role Hierarchy
The role hierarchy enables users above another user in the hierarchy to have the same level of access to records owned by or shared with users below. Consequently, users above a record owner in the role hierarchy are also implicitly granted Full Access to the record, though this behavior can be disabled for specific custom objects. The role hierarchy is not maintained with sharing records. Instead, role hierarchy access is derived at runtime. For more information, see “Controlling Access Using Hierarchies” in the Salesforce online help.

1.3 Sharing Rules
Sharing rules are used by administrators to automatically grant users within a given group or role access to records owned by a specific group of users. Sharing rules cannot be added to a package and cannot be used to support sharing logic for apps installed from Force.com AppExchange. Sharing rules can be based on record ownership or other criteria. You can't use Apex to create criteria-based sharing rules. Also, criteria-based sharing cannot be tested using Apex. All implicit sharing added by Force.com managed sharing cannot be altered directly using the Salesforce user interface, SOAP API, or Apex.

2. User Managed Sharing, also known as Manual Sharing
User managed sharing allows the record owner or any user with Full Access to a record to share the record with a user or group of users. This is generally done by an end-user, for a single record. Only the record owner and users above the owner in the role hierarchy are granted Full Access to the record. It is not possible to grant other users Full Access. Users with the “Modify All” object-level permission for the given object or the “Modify All Data” permission can also manually share a record. User managed sharing is removed when the record owner changes or when the access granted in the sharing does not grant additional access beyond the object's organization-wide sharing default access level.

3. Apex Managed Sharing
Apex managed sharing provides developers with the ability to support an application’s particular sharing requirements programmatically through Apex or the SOAP API. This type of sharing is similar to Force.com managed sharing. Only users with “Modify All Data” permission can add or change Apex managed sharing on a record. Apex managed sharing is maintained across record owner changes.

Account sharing rules can be based on the record owner or on other criteria, including record type and certain field values. You can define up to 300 account sharing rules, including up to 50 criteria-based sharing rules.

1. If you plan to include public groups in your sharing rule, confirm that the appropriate groups have been created.

2. From Setup, click Security Controls | Sharing Settings.

3. In the Account Sharing Rules related list, click New.

4. Enter the Label Name and Rule Name. The Label is the sharing rule label as it appears on the user interface. The Rule Name is a unique name used by the API and managed packages.

5. Select a rule type.

6. Depending on the rule type you selected, do the following:

■ Based on record owner—In the owned by members of line, specify the users whose records will be shared: select a category from the first drop-down list and a set of users from the second drop-down list (or lookup field, if your organization has over 200 queues, groups, roles, or territories).

■ Based on criteria—Specify the Field, Operator, and Value criteria that records must match to be included in the sharing rule. The fields available depend on the object selected, and the value is always a literal number or string. Click Add Filter Logic... to change the default AND relationship between each filter.Note

To use a field that’s not supported by criteria-based sharing rules, you can create a workflow rule or Apex trigger to copy the value of the field into a text or numeric field, and use that field as the criterion.

2. In the Share with line, specify the users who should have access to the data: select a category from the first drop-down list and a set of users from the second drop-down list or lookup field.

3. Select a setting for Default Account, Contract and Asset Access.

4. In the remaining fields, select the access settings for the records associated with the shared accounts.

Access Setting	Description
Private (available for associated contacts, opportunities, and cases only)	Users can’t view or update records, unless access is granted outside of this sharing rule.
Read Only	Users can view, but not update, records.
Read/Write	Users can view and update records.

With sharing rules, you can make automatic exceptions to your organization-wide sharing settings for defined sets of users. For example, use sharing rules to extend sharing access to users in public groups, roles, or territories.Sharing rules can never be stricter than your organization-wide default settings. They simply allow greater access for particular users.

You can create the following types of sharing rules.

Type	Based on	Set Default Sharing Access for
Account sharing rules	Account owner or other criteria, including account record types or field values	Accounts and their associated contracts, assets, opportunities, cases, and optionally, contacts
Account territory sharing rules	Territory assignment	Accounts and their associated cases, contacts, contracts, and opportunities
Campaign sharing rules	Campaign owner or other criteria, including campaign record types or field values	Individual campaign records
Case sharing rules	Case owner or other criteria, including case record types or field values	Individual cases and associated accounts
Contact sharing rules	Contact owner or other criteria, including contact record types or field values	Individual contacts and associated accounts
Custom object sharing rules	Custom object owner or other criteria, including custom object record types or field values	Individual custom object records
Lead sharing rules	Lead owner or other criteria, including lead record types or field values	Individual leads
Opportunity sharing rules	Opportunity owner or other criteria, including opportunity record types or field values	Individual opportunities and their associated accounts

Note

■ You can’t include high-volume portal users in sharing rules because they don’t have roles and can’t be in public groups.

■ Developers can use Apex to programmatically share custom objects (based on record owners, but not other criteria). This does not apply to User Sharing.

Apex Scheduler Class

First apex scheduler class:

global class Scheduler01 implements Schedulable {

global void execute(SchedulableContext SC)

{

//Call other class method which will perform operations as it is

//recommended that all processing take place in a separate class

doScheduling();

}

public void doScheduling(){

try{

dateTime dt=System.now().addMinutes(10); //you can specify 10 mins or 15

//mins or any interval

String Csec,Cmin,Chr,Cday,Cmonth,CYear;

Csec=String.valueof(dt.second());

Cmin=String.valueof(dt.minute());

Chr=String.valueof(dt.hour());

Cday=String.valueof(dt.day());

Cmonth=String.valueof(dt.month());

CYear=String.valueof(dt.Year());

String SchTimer=Csec+' '+Cmin+' '+Chr+' '+Cday+' '+Cmonth+' ? '+CYear;

system.debug('*************SchTimer:'+SchTimer);

Scheduler02 cas = new Scheduler02();

system.schedule('Scheduler02: Running at '+System.now().format(), SchTimer, cas);

//we will delete completed apex scheduled jobs for which state is DELETED

for( CronTrigger c:[Select State,Id,EndTime,CronExpression From CronTrigger where

NextFireTime= null AND State='DELETED' Limit 100]){

System.abortJob(c.id);

}

catch(exception e){

}

Second apex Scheduler Class:

global class Scheduler02 implements Schedulable {

global void execute(SchedulableContext SC){

//Call other class method which will perform operations as it is

//recommended that all processing take place in a separate class

doScheduling();

}

public void doScheduling(){

try{

dateTime dt=System.now().addMinutes(10);

String Csec,Cmin,Chr,Cday,Cmonth,CYear;

Csec=String.valueof(dt.second());

Cmin=String.valueof(dt.minute());

Chr=String.valueof(dt.hour());

Cday=String.valueof(dt.day());

Cmonth=String.valueof(dt.month());

CYear=String.valueof(dt.Year());

String SchTimer=Csec+' '+Cmin+' '+Chr+' '+Cday+' '+Cmonth+' ? '+CYear;

system.debug('*************SchTimer:'+SchTimer);

Scheduler01 cas = new Scheduler01();

system.schedule('Scheduler01: Running at '+System.now().format(), SchTimer, cas);

//we will delete completed apex scheduled jobs for which state is DELETED

for( CronTrigger c:[Select State,Id,EndTime,CronExpression From CronTrigger

where NextFireTime=null AND State='DELETED' Limit 100]){

System.abortJob(c.id);

}

catch(exception e){

}

Salesforce Question And Answer

1. Best option to sum different objects - summary report

2. Console: The console is a tab that combines a list view and related records into one screen with different frames so users have all the information they need when interacting with Salesforce. With the console, users can quickly find, view, and edit records such as cases, accounts, and contacts with fewer clicks and without switching back and forth between screens. Administrators choose the information displayed in the console to accommodate users’ varied and evolving business needs. Console layouts define what objects are available to users in the console’s list view frame. For example, if you want users to see list views of cases and contacts in the console, then you would add both cases and contacts to a console layout, and then assign that console layout to the appropriate user profiles. A user can only view objects in the console’s list view frame if those objects are added to the console layout to which

their profile is assigned.

36. System Fields: Salesforce.com has the ability to set system fields through the API. When you are migrating data from an external system, the API lets customers set the CreatedBy, CreatedDate, LastModifiedByID, LastModifiedDate, and a number of other fields on most objects that were previously read-only. By setting these fields, records will appear to have been created at their original created time from your old system. The objects you can edit audit fields are: Account, Contact, Opportunity, Case, Task, Lead, Event, Custom objects.

37. Encrypted Custom Fields: Encrypted custom fields are text fields that can contain letters, numbers or symbols but are encrypted. The value of encrypted fields is visible to users with “View Encrypted Data” permission.

To enable encrypted fields for your organization, contact salesforce.com.

● Encrypted fields are encrypted with 128-bit keys and use the AES (Advanced Encryption Standard) algorithm.

● Encrypted custom fields cannot be unique, an external ID, or have default values.

● Although other text fields can contain up to 255 characters, encrypted text fields are limited to 175 characters due to the encryption algorithm.

● Encrypted fields are not available for use in filters such as list views, reports, roll-up summary fields, and rule filters.

● Encrypted fields cannot be used to define report criteria, but they can be included in report results.

● Encrypted fields are not searchable, but they can be included in search results.

● Encrypted fields are not available in the following: Salesforce CRM Mobile, Force.com Connect for Outlook, Force.com Connect for Lotus Notes, Force.com Connect Offline, lead conversion, workflow rule criteria or formulas, formula fields, outbound messages, default values, and Web-to-Lead and Web-to-Case forms.

● You can use encrypted fields in email templates; however, the value is always masked regardless of whether you have the “View Encrypted Data” permission.

● If you have created encrypted custom fields, make sure your organization has secure connections using SSL (Secure Sockets Layer) enabled. To enable this setting for your organization, see Setting Session Security.

If you have the “View Encrypted Data” permission and you grant login access to another user, be aware that the other user will be able to see encrypted fields unmasked (in plain text). To avoid this possibility, first clone your profile and remove the “View Encrypted Data” permission from the cloned profile, then assign yourself to the cloned profile before granting login access to the other user. If you do not have the appropriate permissions to clone and change your profile, contact your administrator for assistance.

Only users with the “View Encrypted Data” permission can clone the value of an encrypted field when cloning that record.

Encrypted fields are editable regardless of whether the user has the “View Encrypted Data” permission. Use validation rules, field-level security settings, or page layout settings to prevent users from editing encrypted fields.

You can still validate the values of encrypted fields using validation rules or Apex scripts. Both works regardless of whether the user has the “View Encrypted Data” permission. Data for encrypted fields in the Debug Log is masked. Existing custom fields cannot be converted into encrypted fields nor can encrypted fields be converted into another data type. To encrypt the values of an existing (unencrypted) field, export the data, create an encrypted custom field to store that data, and import that data into the new encrypted field. Mask Type is not an input mask that ensures the data matches the Mask Type. Use validation rules to ensure that the data entered matches the Mask Type selected. Use encrypted custom fields only when government regulations require it because they involve additional processing and have search-related limitations.

Page Layouts:

a. Page layouts for the user object only include custom fields, custom links, S-controls, and Visualforce pages

b. Tagging, related lists, custom buttons, and standard field customizations are not included on page layouts for the user object

c. Field level security is only available only for the custom fields on User object

d. Field level security is not available for the standard fields on the User object

e. You can define mini-page layout for the User object but can’t add standard fields or related list

f. Only Administrator can use the import wizard for Accounts, Contacts, Leads, Solutions and custom objects

g. Administrator has access to import into any field even if a field is hidden or read only in the page layout or field level security setting

h. Individual users can import only into the fields that are accessible to them via their page layout or field level security settings

i. In Personal, Group and Professional editions page layout control which field user can access in related list, list views, reports, connect offline, email and mail merge templates, custom links.

j. In Enterprise, Unlimited and Developer editions, the access is controlled by field level security

k. When editing a Person Account page layout, if you add shipping address next the billing address in the Address information section a link will display on the person account edit page that lets you copy the billing address into the shipping address. Also, an equivalent link appear if you add other address to the Address information section

l. Contact fields and related list are available on the Person Account

page layouts. However , contact custom links and custom buttons are not available

m. Some Items can only be moved to certain sections on the page layout. For example you can drag a custom s-control to any field section on the page layout, but not to a Related list section or Button section

Visual force:

n. Visualforce uses a tag based markup language to give developers more powerful way to build applications and customize the Salesforce interface. With Visualforce, you can:

i. Create custom user interfaces that easily leverages standards Salesforce styles

ii. Create custom user interfaces that completely replace the Standard Salesforce Styles

iii. Build wizard and other navigation patterns that uses data specific rules for optimal , efficient application interaction

o. Visual force is a framework that lets developers to build sophisticated, custom user interfaces that can be hosted natively on the force.com platform

p. Visualforce framework includes a tag based markup language similar to HTML

q. In Visualforce markup language, each Visual force component correspond to a course and fine grained user component such as related list, page section or a field

r. Developer can use Visualforce to create a Visual force page definition. The page definition consist of 2 things:

i. Visual force markup

ii. Visual force controller

s. Visual force markup: consists of Visualforce tags, HTML, javascript or any web-enabled code

t. Visualforce controller: is a set of instructions that specify what happens when a user interacts with the component specified in the associated visual force markup such as when user clicks on a button or links

u. Controller also provides the data access that should be displayed in a page and can modify component behavior

v. Standard Controller: consists of the same functionality and logic that is used for a standard Salesforce page. If you use a standard controller, clicking on a Save button in a Visualforce page results in the same behavior as clicking Save on the standard edit page

w. Custom Controller: is a class written in Apex that implements all of the page logic without leveraging a standard controller

x. Like other Apex classes, Custom controller also execute entirely in system mode in which the object and field level permissions of the current user are ignored. You can specify whether a user can execute a method in a custom controller based on the user’s profile

y. Controller Extension: A controller Extension is a class written in Apex that adds to or Overrides behavior in a Standard or custom controller. Extension let you leverage the functionality of another controller while adding your own logic

39. Standard controller executes in User mode in which the permissions, field level security and sharing rules of the current user are enforced

40. Because standard controllers execute in user mode—in which the permissions, field-level security, and sharing rules of the current user are enforced—extending a standard controller lets you build a Visualforce page that respects user permissions. Although the extension class executes in system mode, the standard controller executes in user mode. As with custom controllers, you can specify whether a user can execute methods in a controller extension based on the user’s profile.

41. Custom picklist can be controlling or dependent

42. Standard picklist can only be the controlling

43. Standrad picklist can not be dependent

44. A dependent field works in conjuction with a controlling field to filters its values. The value chosen in the controlling field effects the values available in the dependent field

45. The field that drives filtering is called as Controlling field.

46. Standard and Custom checkboxes can be the controlling field

47. Standard and Custom picklist with at least 1 and less then 300 values can be the controlling field

48. The field that has its value filtered is called as Dependent field

49. Custom picklist and multi-select picklists can only be the dependent fields

50. Universally Required:

a. Always require a value in this field in order to save a record

b. Required across all record types

c. Always display on edit page

51. Universally Required only works in Custom fields

52. Universally Required does not work in Standard fields

53. Unique:

a. Don’t allow duplicate values

b. Treat “ABC” and “abc” as duplicate values (case insenstive)

c. Treat “ABC” and “abc” as different values (case senstive)

54. Textarea can’t be a unique field

55. We can set the External ID of a field only for the TEXT, NUMBER and EMAIL data type for the custom fields. Means External ID can only be for custom fields of type TEXT, NUMBER and EMAIL

56. External IDs is available on all objects which support custom fields

57. User defined cross-referenced field

58. Why it is important:

a. Increases Report and API SOQL performance

b. Used with Upsert to easily integrate app with other systems

59. An object can have 3 external ID fields

60. An external ID contains record IDs from a system outside of Salesforce. You can match against this field during importing or integration, or when using the upsert call. Also, external ID fields are indexed, so selective filters on them should run quickly.

61. Encrypted Fields: Encrypted fields allows for masking data from all the users except those with “View Encrypted Data” permission. This is provisioned feature and you must contact with Salesforce.com to enable it

62. Encrypted custom fields can not be Unique fields

63. Encrypted custom fields can not be External ID fields

64. Encrypted custom fields can not have default values

65. Encrypted fields can be modified regardless of whether the user has “View Encrypted Data” permission

66. How can we prevent user to modify the Encrypted fields:

a. Use validations rules, field level security setting or page layout setting to prevent the user from editing encrypted fields

67. Object Relationship:

a. A relationship is a bi-directional association between two object

b. Relationship allows us to create links between one objects to other

68. Force.com platform support the following 4 types of relationship:

a. Lookup relationship

b. Master-detail relationship

c. Many-to-Many relationship

d. Self

69. Lookup Relationship:

a. Creates a loosely typed relationship between two objects

b. Child row is not automatically deleted when parent row is deleted

c. No inherited sharing and security. Means the child row does not inherit the sharing and security from the parent record

d. 25 lookup relationships can be created per object. We can create maximum 25 lookup on a record

e. Lookup field data on child record is not necessarily required. Means the Lookup field value can be null on child record

70. Mater-Detail relationship:

a. Mater-Detail relationship closely links two objects together such that the master record controls certain behavior of the detail record

b. When a master record is deleted, the detail record is automatically deleted

c. Owner field on the Detail record is not available

d. Owner field on the Detail record is set to the owner of the Master record

e. Owner of the Detail can not be different for Master and Detail record

f. The security setting for the master record controls the detail record

g. Same security and sharing setting are applied on Detail as on the Master record

h. The Master-Detail relationship field (which is the field linking the two objects) is required on the Page Layout of the Detail record

i. Only 2 Master-Detail relationship are allowed per object

71. Many-To-Many Relationship:

a. Allow for the relationship of 2 objects in a Many-To-Many fashion

b. Implementing a Many-To-Many relationship requires a third junction object

72. Junction object: When modeling a many to many relationship, you use a junction object to connect the two object

a. Junction object is a custom object with two master detail relationships

b. When creating a junction object, consider the following things:

i. Name the object with a label that indicates it’s purpose

ii. Use the auto number data type

73. What is a Custom App: A custom application is a logical container for all the objects, tabs, processes and services associated with a business function

a. A force.com app consist of a name, description, an ordered list of tabs, optionally a custom logo and default lending page

b. Salesforce.com provides standard apps like Sales, Marketing, Call Center

c. Custom App display CustomForce logo by default

d. You can insert your own logo, you need to upload it in to the Document object as a JPG or GIF file. The logo size should be less then 20 KB size

e. You can set your landing page from the Default Landing tab drop down menu

74. What is a Custom Tab:

a. A custom Tab is a user interface component, you create to display custom object data or other web content embedded in the application

b. There are 3 types of custom tabs:

i. Custom Object Tab :: display the data of custom object in user interface

ii. Web Tab :: display any external web based application or web page in a user interface

iii. Visualforce Tab::Display any visual force page

c. Universal Container wants to make sure that user will be able to easily access the new custom objects they have created. They need to create new custom tabs that will quickly guide the people

75. Page Layouts:

a. Page Layout defines the organization of

i. Fields

ii. Custom Links

iii. Visual force pages

iv. Custom s-control

v. Related Lists on an object detail page or edit page

b. Page Layout customizations include

i. Field locations

ii. Page section customizations

iii. Field property: Field property can be “read only, required”

c. Page layout standard section names can not be modified for standard page layouts

d. Making a field required on a page layout or through field-level security ensures users must enter a value

e. If you make a user field universally required, you must specify a default value for that field

f. Use field-level security as the means to restrict users’ access to fields; then use page layouts primarily to organize detail and edit pages within tabs. This reduces the number of page layouts for you to maintain

g. Field-level security does not prevent searching on the values in a field. If you do not want users to be able to search and retrieve records that match a value in a field hidden by field-level security, contact salesforce.com Customer Support for assistance with setting up your organization to prevent unwanted access to those field values.

h. Page layouts can specify whether a given field is required, but the API does not enforce such layout-specific field restrictions or validations in create() and update() calls. It is up to the client application to enforce any such constraints, if applicable

i. Means if a field is set to required from page layout, the API will not enforce the user to make it as required

j. Record types can control which picklist values can be chosen in a given record and which page layouts users with different profiles can see. However, such rules that are configured and enforced in the Salesforce user interface are not enforced in the API. For example, the API will not validate whether the value in a picklist field is allowed per any record type restrictions associated with the profile of the logged-in user. Similarly, the API will not prevent a client application from adding data to a particular field simply because that field does not appear in a layout associated with the profile of the logged-in user

k. When a custom object is created, a Tag object related to it is also created. These object names are of the form: MyObjectName__Tag, similar to AccountTag and other standard object tag objects.

l. In the Salesforce user interface, you can mark a custom field as required, and this is also enforced in the API. Every custom field has a field isRequired, with a data type boolean. The default value is false. If set to true, every request must supply a value (or leave the current value) to this field. Otherwise, the request will fail. Once the value is set to true, the next time the field is edited or created, the validation will apply, and if there is no value supplied or default value specified, the request will fail.

m. To edit the isRequired field, you must log in as a user with the "Customize Application" permission

76. Workflows:

a. Standardize the internal procedure and automated the business processes

b. Event based and time-dependent triggering engine

c. Capabilities of workflow:

i. Field updates: restricted to updates on source object only

ii. Tasks and alerts

iii. Outbound messaging

iv. Approval Process

v. More sophisticated workflows may require use of API

d. Workflow rules are automated processes that trigger criteria based on your business requirements

e. Workflow have two parts:

i. Rule criteria: which records should trigger the rule

ii. Workflow actions: what should happen once the rule is triggered

f. Each workflow rule consist of the following:

i. Criteria that cause Salesforce to apply the workflow rule.

ii. Immediate actions that execute when a record matches the criteria. For example, Salesforce can automatically send an email that notifies the account team when a new high-value opportunity is created

iii. Time-dependent actions that Salesforce queues when a record matches the criteria, and executes according to time triggers. For example, Salesforce can automatically send an email reminder to the account team if a high-value opportunity is still open ten days before the close date.

g. Workflow Evaluate Criteria:

i. When a record is created, or when a record is edited and did not previously meet the rule criteria

ii. Only when a record is created

iii. Every time a record is created or edited

h. Immediate Workflow Actions:

i. New Task

ii. New Email Alert

iii. New Field update

iv. New outbound message

v. Select existing action

i. You can’t add a time-dependent workflow action for “Every time a record is created or edited” evaluation criteria

j. For Email Alert action the Recipient type can be the following items:

i. User

ii. Creater (record creator)

iii. Owner

iv. User

v. Public groups

vi. Role and subordinates

vii. Roles and internal subordinates etc..

k. For Email Alert action we can enter 5 email addresses to be notified in the Additional emails

l. You cannot add time-dependent workflow actions on an active rule. You must de-active that rule and then add the time trigger

77. Formula Fields: A read-only field that derives its value from a formula expression you define. The formula field is updated when any of the source fields change.

a. The output type for a formula field can of these types:

i. Currency (18 decimal places)

ii. Date

iii. Date/Time

iv. Number (18 decimal places)

v. Percent (18 decimal places)

vi. Text

b. Formula field help text displays on the detail page

c. Formula field are not displayed on Edit page and auto calculated

d. Smart custom fields that can be used to build business specific calculations using simple wizards and excel like formula calculations

e. Supported on standard and custom objects

f. Formula fields can reference standard, custom or other formula fields

g. Formula fields can reference fields on related objects

h. Cross object formula fields:

i. Cross objects formula fields enables you to incorporate the merge fields from multiple objects for calculations and display

ii. Create formula that reference fields on parent or grandparent objects up to 5 level

iii. The cross object formula fields can refer the objects up to 5 levels

iv. This enables to display fields from related objects on detail pages

v. Use a simple wizard to browse across objects and insert fields in formula

i. Formula fields only display on detail pages

Salesforce and Apex