Salesforce Easy Learn: Salesforce Tutorial for certification(Developer 401)

Salesforce Applications

To access Force.com platform visit the URL https://login.salesforce.com and click on the Setup link in the top nav bar.
To access apps, select Create|Apps menu in the left navbar.
To create a new Application, a developer needs to specify App Label, App name, description, custom app logo and a list of tabs. App Label is displayed to users, and App name is the internal name referred in code.
An application is a set of tabs.
Tabs are of three types
1. Custom object Tab
2. Web Tab
3. Visual force Tab
Tabs are used to organize objects and records. Each tab is associated with a unique object. A tab also lets you specify a color and an image.
One of the tabs in the application is a default landing page.
Saved applications appear in the Apps menu on the top left navbar
Salesforce provides a Force.com IDE. This is an eclipse plugin application that provides a development environment for VisualForce and Apex.
In Salesforce code without desired test coverage cannot be deployed. A minimum of 75% test coverage must be achieved before deployment.
Native User Interface refers to the default user interface that Salesforce provides

Force.com's objects, fields and relationships

Objects logically correspond to database tables in a relational database. Fields of an object is similar in concept to column in relational database.
Objects can be standard or custom. Standard are objects are predefined by Salesforce like Accounts, Case, Contact etc. Custom objects are created by developers based upon application requirements.
Custom objects have the following characteristics
1. Custom objects store information that is unique and important to your organization.
2. Custom objects are reportable and search-able.
3. Custom objects have configurable access control features.
Force.com provides undelete functionality on objects. Deleted objects go to a recycle bin with an expiry date of 45 days. An administrator may delete objects from recycle bin.
Fields of type Picklist cannot be made required.
There are three type of page layouts:
1. Detail
2. Mini
3. Console
Objects have following fields that need to be entered by developers -
- Label
- Plural Label
- Object Name
- Description
- Record Name
- Record Type
The field for record name is displayed by default when the object has to be displayed (for example in search results). The record type can be text or auto-number. Auto-number can take values like A-{0001}, A-{0002} etc.
The Object name is used to access the object programmatically. __c is added as a suffix to the custom object names. The label name is used for display of the object.
The standard fields are added automatically. Examples of standard fields are Created By, Owner etc.
Custom Fields are added to an object by developers. In the custom object definition detail screen there is a section of custom fields. Click New to create new custom fields in this area.
Custom Fields have properties like:
- Data Type
- Field Label
- Field Name
- Required checkbox
- Description
- Default Value

Examples of valid field types are

Field Type	Comments
Text	Text can be upto 255 characters
Text Area	Text Area can be either 255 characters or 32K characters
URL
Picklist	Can be single select or mult-select. The developer needs to provide valid values
Currency
Checkbox
Percent
Number

The field types are aligned to user interface elements like picklist and checkbox.

Changing the data type of existing custom fields is possible, but doing so may cause data loss.
Fields can be set as unique, required or as external id. A required field is always displayed in the edit page. A field of type external id is a record id from another system. The performance of reports and SOQL is better for fields defined as external ids. Fields of type number, text and email can be set as external id. Each object can have up to three external ids.
A field defined as encrypted is not visible to users. Typical usage of encrypted field is for password. Only users with "View Encrypted Data" can view the encrypted fields. Encrypted fields are editable.
1. This is a provisioned feature, so you must contact Salesforce to enable it.
2. Encrypted custom field cannot be unique, an external ID, or have default values.
Objects can have upto 500 custom fields.
When an object is created, a user interface is created automatically for Create, Update, Read and Delete operations.
Fields of two Picklists can be made dependent on each other. As an example consider an application with customers in US and Canada. If there are two picklists - one for country and the other for state. Based upon user's selections of country, the state settings need to get updated. This is implemented by defining controlling and dependent picklists. In the above scenario, country becomes the controlling picklist and state becomes dependent picklist. The controlling and dependent picklists are defined using "Field Dependency" button in "Custom Field and Relationship" section.
Standard picklist can be controlling picklist but not dependent picklist. Maximum number of values allowed in controlling field is 300. A custom multi-select picklist cannot be controlling field in a picklist.
Merge fields are fields that display values based upon formula calculations.
Salesforce supports history tracking on change in values of fields. This can be enabled for up to 20 fields in an object.
Custom objects can be represented using a Metadata XML.
Deleted data and metadata is stored in recycle bin.
Database tuning is managed by Salesforce. How Objects and fields are stored in the database is internal to Salesforce.

Object Relationships

Force.com allows you to create relationship between objects. The "Custom Fields & Relationship" section of objects is used to define relationship between objects.
There are a two types of object relationships that Salesforce supports -
1. Lookup relationship
2. Master-detail relationship
These relationships are used to implement one-to-many relationship. They are created as fields in the child record. As an example in a recruitment application if one applicant can have many interviewFeedbacks, we could create a lookup (or master detail) relationship in the interviewFeedback object pointing to the applicant object.
In Master Detail relationship, if the parent record is deleted, then all its children records are deleted.
Child records in master-detail relationship do not have owners. They inherit ownership from the parent record.
In Master detail relationship, the parent field is required. Also the parent field once specified cannot be changed.
Standard Object cannot be on detail side of Master-Detail relationship.
In the related list section of parent objects, only one field of the child object is displayed by default. This is the field specified as Record Name in the child object. To add more fields, search lookup layout needs to be updated.
Rollup-summary fields are supported in master detail relationship. The parent object can use roll-up summary field type to perform operations of sum, maximum, minimum, count among its children records. These fields are read only fields and are used to calculate values from a set of records.
Many-to-Many relationships are implemented using two master-detail objects. One Junction object is used as the child of the objects between which many-to-many relationship needs to be established.

The table below compares Master Detail and Lookup relationship

	Lookup relationship	Master Detail relationship
Is Parent a required field	No	Yes
Maximum number of relationship in an object	25	2
Security of parent determines child record's access	No	Yes
Deleting parent record deletes children	No	Yes
Parent can be a child in another relationship	Yes	No
Roll-up summary in parent supported	No	Yes

Self relationship is a lookup relationship to itself. An example usage could be organization chart where an employee's manager is also an employee.
Hierarchy Relationship exists only for User object. In this, developers create a manager field in User object to relate to another object.

Approvals and Workflow in Salesforce

Salesforce provides extensive support for implementation of workflow and approvals.

A queue can hold a predefined set of objects and consists of a set of users. Any of the queue members can pick up tasks assigned to the queue. Users or Queues can be owners of records.

Approval processes

The approval process consists of the following steps -
1. Process definition
2. Initial submission actions
3. Step definitions
4. Final Rejection actions
5. Final Approval actions
6. Final Recall actions
The Process Definition step consists of the following sub-steps:
1. Provide the name of process
2. Specify entry criteria for records
3. Specify who is going to approve
4. Specify email template
5. Fields to be displayed in the approver page
6. Specify who is going to send approval mail
Workflow rules are like triggers. Action is triggered when a record meets an evaluation criteria. Workflow rules definition does not impact existing records. Workflow rule gets applied to new record creation or edits.
Workflow rule consists of three steps
1. Select the object
2. Specify evaluation criteria (when should the workflow rule be executed, example for new records are created)
3. Define rule criteria (example when status of job applicant is approved)
Workflow actions can include sending an email, setting values to fields, sending an external message or creating a task.

There are two differences between Workflows and Approval process

Workflow	Approval process
They are activated when a record is saved.	approval process are triggered by explicitly clicking the "Submit for Approval" button.
Workflow consists of single step and single action	Approval process consists of multiple steps. Also different action is taken based upon whether the record is approved or rejected.
Workflows can be modified or deleted.	In approvals some attributes cannot be modified. Processes must be deactivated before approvals can be deleted.

Time-based workflow allows action to be triggered after a delay. As an example we could implement following business logic using time-based workflow: In a recruitment application if for no high priority position no candidates are assigned in a week, then send a mail to Recruitment Manager.
Time-based workflow cannot be executed when evaluation is set to "Every time a record is created or updated".
Approval processes can be single or multiselect process. Multi-select processes require end user authorization for record promotion.
Approval process is unique for object type.
Parallel approval process allows specifying (upto 25) multiple approvers simultaneously. The approver setting could be set to unanimous or first action. In unanimous parallel approval process, all approvers must approve a request, before it is considered as approved.
Possible actions of workflow and approval process are -
1. Creating a task
2. Sending a message to external system (outbound message)
3. Updating a field value
4. Sending an email
5. Locking a record
Outbound message helps keeping salesforce coordinated with other applications.
Dynamic approval process is used to route approval requests to users listed in lookup fields on the record requiring approval. In this, approver names are defined dynamically from an object.
Process Visualizer provides Read only visual of an Approval process. It can be accessed by clicking on “View Diagram” button.

Salesforce Business Logic

Validation Rules
Assignment Rules
Auto Response Rules
Workflow Rules
Escalation Rules

Validation rules can be attached to fields. They are executed when a record is created or updated.
When defining a validation rule, an error condition and error message are defined. If evaluation of error condition results in true value, record is not saved, and the error message is generated.
Some fields are of type Formula. They are derived from other fields. Validation rules and formula follow the same expression language.

A set of functions used in Formulae are included below.

Formulae	Description
TODAY()	Returns todays date
IF(expr,x,y)	if expr is evaluated to true, x is returned, else y is returned
TEXT(field)	Returns the text value of a picklist
ISPICKVAL(field,value)	Checks whether value of field matches the input parameter. Returns true if there is a match
ISBLANK(field)	Returns true if field is blank
AND(expr1,expr2)	Performs a logical AND
OR(expr1,expr2)	Performs a logical OR
HYPERLINK(url,text)	Creates a link to the specified url
ISCHANGED(field)	Checks id the field's value has changed
PRIORVALUE(field)	Returns the previous value of field
ISNEW()	Returns true if a new record is being created.
INUMBER()	Returns true if the field is a number
IMAGE()	Used to display an image
REGEX()	Compares a text field to a regular expression and returns true if there is a match
VLOOKUP()	In an object consisting of key value pair, VLOOKUP returns value for a key

A few things on these functions:

Case(), If() and IsNumber() are available for all features like approval, workflow, validation and formula.
Image() is only for Formula fields.
Vlookup() is for Validation rules.
IsChanged() and PriorValue() are for workflow, only when “everytime a record is created or updated”.

Methods are used in Formulae fields, Validation rules, Workflow rules, Field updates, Default values and Approval process. Some of these methods are only available in certain areas. CASE, IF, ISNUMBER are available in all places. IMAGE is available only in formulae fields. VLOOKUP is available only in validation rules.
Cross-object formula span two or more objects by referencing merge fields.
Difference between Roll Up and Cross Object Fields:
1. In cross object formulas, we navigate from child object to parent or grand parent object(up to 5 levels). Field is displayed on child object. While in Roll Up Summary Fields, we navigate from Parent to Child object.
2. Formula fields do not store the value on the record but Roll Up Summary fields stores the value and changes can be seen on parent.
Limitations of Cross Object Fields:-
1. You can’t reference cross obect formula in roll up summary field.
2. You cannot reference merge field for objects related to activities.
3. You cannot reference record owner merge field for any object.

Debugging Tools

View Setup Audit Trail is used to view list of configuration changes. It is available in Security Controls menu in the Setup area. Examples of audit trail are creation of object, adding a new field, changing field type or setting up a new approval process. By default 20 last configuration changes are displayed. Changes made in last 180 days can be exported into a csv file. It can be configured by admin or developer.
Field history tracking can be enabled at object level at the time of creation of objects. Up to 20 fields can be tracked for one object. As an example, any changes in field values are stored as part of Field history tracking. During Field history tracking, Time of change, user who made the change, prior value and new values are stored. For data types Multiselect Picklist and text area (long), previous and new values are not saved.In the Custom Fields and Relationship area of Object configuration, "Set History Tracking", is used to enable field level tracking. Review History related list can then be added to page layout to view changes to fields.
Force.com platform provides three main mechanisms for debugging errors. These are also known as Auditing tools:-
1. Field history allows developers to track changes to field values of up to 20 fields for any object.
2. Debug Logs is a persistent store in which logs are stored for transactions performed by up to 20 users.
3. System Logs allows developers to run apex commands and view the logs
4. Setup Audit trail allows developers to view all configuration changes (example creation of object, changing field type, creating a workflow etc.) made in last 180 days.
Setup Audit Trail of Salesforce is used to track configuration changes made. Example of configuration changes are date of change, description of the change, user who made the change. Twenty most recent changes are displayed in the audit trail. Last 180 days changes can be exported into a csv file. View Setup Audit Trail feature is available via the Security Control menu.
There is a link to System Log at the upper right corner of the page. System Log allows developers to enter Apex code and see the results of running this code. System Log display information about workflow rules, validation rules, debugging information and resource utilization.
To control quantum of logging, system log takes two parameters Log category and Log level. Log categories can take the following values -
- None
- Database
- Workflow
- Validation
- Callout
- Apex code
- Apex profiling
Log level indicates level of detail in the message. It takes the following values
- None
- Error
- Warn
- Info
- Debug
- Fine
- Finer
- Finest
Debug log is an organization-wide persistent log. It can store debug log for transactions performed by specific users. Logs for up to 20 users can be persisted. Debug Log is available via the Monitoring menu.
Salesforce supports history tracking on change in values of fields. This can be enabled for up to 20 fields in an object. In Custom Fields and Relationship, set history tracking is enabled for a set of fields. Review history can be added to page layout. Information stored includes - changes to field values, time of change, user who changed the field. Old and new values of fields are not stored for multi-select picklist and long text area.

Salesforce DataLoader

Every object has a standard field called id. There is no need to define an explicit primary key in custom objects. The standard id field can be used as primary key.
The id is alphanumeric. id can be either 18 digit case-insensitive or 15 digit case-sensitive.
The first three characters of the id identify the object. Ids can be identified in three ways -
- From the URL when a record is displayed in Salesforce
- From reports
- Through the web services api. Data Loader uses web services api to display the ids.
The id displayed by a report is the 15-digit case-sensitive id. The ids returned by web services api are 18-digit id. For updates web service accept both the 15-digit and 18-digit ids.
15-digit id can be converted to 18-digit id and vice-versa.
There are two types of Data Loader logs:
- sd1.log
- sd1_out.log
When loading data into a salesforce application dependencies between objects determine the order in which objects are loaded. If there is a one-to-many relationship between A and B, the data for A should be loaded before the data for B.
Data Management is an ongoing process to keep data in your application up-to-date, accurate and clean whereas Data Migration is one time task.
External ids option can be specified on custom fields for fields of type text, number or email. This creates custom index in database. A maximum of three fields can be set as external ids. Specifying a field as external ids, leads to improved reporting and SOQL performance. External ids prevent duplicate entries when exporting data. Both upsert and external ids are used for migration and integration of data.
If "Modifiable System Field" configuration is enabled, then system fields (like creation date) can be set to any value during initial data load. These values can however not be updated after the initial upload. These fields are accessible through the API. These are backward compatible with all SOAP based APIs available for all custom objects. These are Read only fields.
Salesforce determines an operation Upsert. Upsert stands for update + insert. When an upsert is performed, if a record exists it gets updated. If the record does not exist, it gets inserted. This is useful in large data uploads, and if the connectivity is not stable. Matching of record can be performed on the basis of Salesforce id or External id. When performing an upsert, only single external id field is used.
Import wizard are available via the standard Salesforce application using easy to use interface and do not require programming. Import wizard can be used to load up to 50,000 records. Import wizard can be used for de-duplication of data. Import wizard can be used to import accounts, contacts, leads, solutions and custom objects.
Web Services API based tools can load more than 50,000 records and can support all object types. It also allows developers to schedule regular data loads. These support nightly feeds. APIs can delete multiple objects at the same time.
Data Loader is an API based product by Salesforce. It can be run from command-line. It can generate and import from csv (Comma Separated values) files. It supports custom relations imports using upserts. It also support loading from JDBC.
Data Loader can be installed on a desktop from the Salesforce Data Management menu. Operations supported by data loader are -
- Extract
- Upsert
- Insert
- Delete
- Update
Command-line version of data-loader supports regular scheduling of loads.
Mass Transfer Tool is used to transfer multiple objects data from one user to another. User should have the following permissions:
- Transfer record permission
- Edit permissions
The tool can be used to change the ownership of the record.

Force.com development platform

Salesforce provides two type of licenses
1. Salesforce: full access to CRM standards, Force.com custom and application exchange apps
2. Salesforce platform:. Salesforce platform license allows access to custom apps, it does not allow access to online CRM product.
Feature licenses can be purchased for additional features such as Marketing User, offline user, Apex mobile user etc. CRM access means access to Standard objects like Cases, Campaigns, Opportunities etc. Platform access means access to Custom and Standard objects.
Force.com platform uses the standard Model View Controller design pattern. The MVC pattern is implemented as below in Force.com platform.

Pattern Force.com implementation

Model Object (custom or standard)

View VisualForce pages

Controller Logic written in Apex that controls navigation
The Create menu is used to provide the declarative framework of Force.com platform. The Develop menu is used to provide the programmable framework.
Page Builder is used to generate user interface for CRUD (Create, Read, Update, Delete) operations of objects. This user interface is created automatically by Salesforce and can be used to create reasonably complex applications withot writing VisualForce or Apex code.
Salesforce allows data types of existing fields to be changed, however this may lead to loss of data.
When you add a custom object tab, all the following will be accessible with the object:
- Recent items
- Sidebar search
- Added to new link/ Create new object drop down
To make a field required, there are a few different ways.
- Check the box for required on Object Definition
- Create a Validation Rule
- Specify that the field is required in the Page layout
Page Layout supports a drag-and-drop interface to develop screens. It allows addition of space and sections, and moving of fields across the screen. It supports making a field read-only or required.
There are two type of activities:
- Task: It is related to a record , assigning a task
- Events: Any calendaring event, meeting etc
A deleted record is stored in recycle bin with an expiry date. Deleted records can be recovered for upto 45 days.
SOQL stands for Salesforce Object Query Language. SOQL is used for performing queryies on objects.
SOSL stands for Salesforce Object Search Language. SOSL is used for performing full text search.
S-controls were used to upload contents such as java applets or active X controls for use in dynamic custom links or web tabs. These have been superseded by visualforce pages. S-controls provide client side programming.
Salesforce provides sandboxes that may be used for development and testing. Full Copy Sandbox allows copies of metadata/configuration along with all the application data to be copied from production to a sandbox environment. The sandbox can then be used for testing and simulating reported problems. Record ids in production and full copy sandbox are also same.Configuration only sandbox copies all your production organisation’s reports, dashboards but exclude all your organisation’s standard and custom object records, documents and attachments. There is a size limit of 500MB(250,000 records)
Developer sandbox is a special configuration sandbox only for single developer. It also allows copying of metadata and configuration, but not copying of application data. Changes from the active development can be isolated until they are ready to be shared. Size limit is 10MB(5000 records)
Developer edition license does not allow copying of configuration from production developer environment.
Territory Management: It is used to define more than 1 role hierarchy.

Pattern	Force.com implementation
Model	Object (custom or standard)
View	VisualForce pages
Controller	Logic written in Apex that controls navigation

Reports and Dashboards in Salesforce

Salesforce provides powerful reporting and generation tools on the data stored in the objects.

In reports data displayed is as per running user's security access. Reports can be run on both standard and custom objects. Reports are stored in folders. Users with access to these folders can run the reports.
Reports data is always generated in real time. When a report is saved, reports configuration parameters are stored - but the generated data is not stored.
There are four type of reports
1. Tabular report. This is the most basic report. It displays just the row of records in a table like format with grand total. Tabular reports cannot be used for generating dashboards.
2. Summary report. This is the most commonly type of report. It allows grouping of rows of data. It supports sorting and displaying subtotals. For example in a recruiting app, a summary report could be used to display open positions classified by department name.
3. Matrix report. This is the most complex report format. Matrix report summarize information in a grid format. Matrix reports allows records to be grouped by both columns and rows.
4. Joined report:A joined report can contain data from multiple standard or custom report types. You can add report types to a joined report if they have relationships with the same object or objects. For example, if you have a joined report that contains the Opportunities report type, you can add the Cases report type as well because both have a relationship with the Accounts object.
Summary and Matrix reports can be used to generate dashboards.
Reports provide two options of exporting data into Excel.
1. Printable View - Export report with formatting into Excel
2. Export Details - Export raw data
Reports present in public folders can be emailed to SalesForce users.
Report display upto 2000 rows of data. Larger reports can be emailed to Excel.
Generation of reports requires following steps.
1. Selection of object
2. Selection of report type
3. Select type of information to be displayed (example count, average)
4. For summary and matrix reports, specify how fields should be grouped
5. Select columns on the report
6. Select column order on the report
7. Specify filtering criteria which should be used to select records
Custom reports let the developers define which all fields should be available in a report. Custom report allows user to change field names. Custom reports allow developers to select related fields (upto four levels). The custom reports also allow developers to add sections to group fields. Once a custom report is created it is available in reports tab and user may create reports from it.
Object relationships that are supported by Custom Report Types are -
1. Include all records that have children
2. Include all records that may or may not have children
As an example consider a recruiting application with two custom objects Position and InterviewFeedback. Also assume that InterviewFeedback is the child of Position object. The first option above will display only those Position objects that have at least one InterviewFeedback as their child. The second option will display all Positions. It is not possible to display Positions that do not have any InterviewFeedback using Salesforce's reporting mechanism.
There are three steps in creating custom reports -
1. Select an object, folder and report label.
2. Select related objects that need to be included.
3. Select fields available for report using a drag-and-drop layout editor.
Custom report types are available via the menu option Create-->Report Types
Analytical snapshot allows reports run at scheduled time to be stored as objects. Analytical snapshots are used to perform trend analysis. As an example if we want to view how monthly sales are growing, fields in a report with sales figure can be stored in a custom object every month using Analytical snapshot. Data in this custom object can then be used to perform trend analysis.
Analytical snapshot are available from the Data Management menu option. Source report in Analytical snapshot can be of the type Tabular or Summary.
Setup Analytical reports require a four step process
1. Select source report
2. Select custom object
3. Map source report fields to custom object fields
4. Schedule the frequency for taking the snapshots
There are two type of Reports
1. Standard Report type
  - Created when a object is created
  - created when relationships between objects are created
  - Always inner joins
  - Cannot be modified.
2. Custom Report type
  - Created by Admin or users with “Manager Custom Report types”.
  - Used to streamline the reporting process.
Key concepts on Custom Report Type
1. Saving a custom report only saves the parameters of the report. The data is always real time.
2. CRTs are reporting templates that admin or users create to streamline the reporting process.

Dashboard

Dashboards are graphical representation of reports. Dashboards can be generated for summary or matrix reports (and not for tabular reports). Dashboards display data as per last time report was run.
A dashboard can have upto 20 components

There are five type of dashboards

Chart	Used for comparisons
Table	Good for showing top five, bottom five lists.
Gauge	Used to show progress towards a goal
Metric	Shows a single number
VisualForce page	used to pull data from other sources

Further there are six type of charts
1. Vertical column
2. Horizontal bar
3. Line
4. Donut
5. Funnel
6. Pie
Funnel is used to show proportion of values against each other. Pie is used to demonstrate proportion of single value against total. Donut is used to demonstrate proportion of single value against total and also show the total value.
The folder in which dashboards are stored determines which user has access to running the dashboard. The dashboard data is based upon the reports data. When a user views the drill-down report for a dashboard component. running user's access permissions determine what data is displayed on the drilldown report. Hence it is possible that the data in the drill down report does not match the cumulative dashboard data.
Dashboard also support automatic refresh and email. The refresh and email can also be scheduled at intervals - daily, weekly, monthly.
Two things that determine access to dashboards:
- Dashboard Folder
- Running User

Limitations of Salesforce reports

Although fairly powerful, Salesforce reports have certain limitations. These are explained below.
1. Support for trend analysis in Salesforce is fairly limited.
2. User Interface of Salesforce reports and dashboards is fixed. Salesforce does not support pixel perfect report.
3. Salesforce reports do not support importing data from other sources
4. When displaying objects and their children, Salesforce does not support reporting on objects that do not have any children.
5. If an object has two different related lists, then Salesforce reporting does not support displaying both these related lists together.
To work-around these limitations, Salesforce customers have the following three options.
1. Reporting as a service: Data resides on Salesforce. New Reports get generated from same data source
2. BI as a service: Data is moved to a different destination on cloud. Reporting is performed on this new data server.
3. Datawarehousing as a service: Data is exported to the customers server and reports are generated from the server located at customers location.

Overview of Security in Force.com development platform

Every user in Salesforce has a profile. Profiles are of two types.
1. Standard profile
2. Custom profile
A user's profiles determines access to objects, and fields in objects.
There are six type of standard profiles -
1. Standard user
2. System Administrator
3. Contract Manager
4. Marketing User
5. Read Only
6. Solution Manager
Profiles control-
1. The objects the user can access
2. The fields of the object the user can access
3. The tabs the user can access
4. The apps the user can access
5. The page layout that is assigned to the user
6. The record types available to the user
Standard profiles cannot be deleted. Access permissions to objects (and their fields) of standard profiles cannot be edited. Standard profiles have access to all standard objects. Read-only profile have read-only access to objects. However access to tabs and applications can be configured for standard profiles.
Access permissions of Custom profiles can be edited. Custom Profiles are created by developers by cloning from a standard profile.
For each profile one application has default status.
Record Types are associated with profiles. Record type play two important roles in Salesforce -
1. They help define values to be shown in picklist for different profiles.
2. They are used to define a mapping between page layout and profiles. This ensures that different users are displayed different views of the same page, depending upon the layout template selected.
A record is an instance of an object.
Removing a field from page layout does not ensure that security of that field. The field may still be accessible using the API.
Security in Salesforce is defined at multiple levels. These levels are -
1. Security at object level
2. Security at field level
3. Security at record level
Object level security is given to profile level. Object level security is set up via Manage Users-->Profile section. Access for Read, Create, Edit & Delete can be set at standard and custom objects.
Field-level security is also applied at profile level. The field-level security is available via the "Set Field-level security" button in the field definition page. At field level, for each profile valid settings are Visible and Read-only.When a user logs in the list of objects that are displayed to her is determined by object level security, and list of fields that are displayed to the user is determined by field level security settings of that profile.
The next set of security concepts work at record level. These constraints determine which records should be displayed to the users. The four constraints that determine record level access are - organization-wide defaults, role-hierarchy, sharing rules and manual sharing.
OWD stands for Organization wide defaults. This setting is defined at object level. OWD defined the default record level sharing for objects. All profiles get at least the privileges defined in OWD. OWD takes three different values -
1. Private (Cant view and edit)
2. Public Read only (Can view)
3. Public Read-Write (Can view and edit)
Key concepts about Organization wide default -
1. To find out what should be set as OWD for an object, first find out which user requires least access to an object. OWD is set based upon this users access requirement.
2. Most restrictive record access is defined using OWD. Access to additional records is made available through Role hierarchy, Sharing rules, Manual sharing.
3. We can set OWD settings for both Standard and Custom Objects.
4. Changing OWD settings can delete Manual Sharing if that sharing is no longer needed.
5. Public Read/Write is default OWD settings.
Role Hierarchy allows additional users access to records. A hierarchy of roles is defined based upon access requirements at record level. Each user belongs to a unique role. If a role has access to some record, than its parent and ancestors will also have access to this record. Roles can be created using the Manager Users menu. Roles are used to control record access, where as profiles are used to specify access at object and field level.
Public group used in a sharing rule. It is used to give access to folders. It consists of users, roles or "roles and subordinates". The default Public Group is “Entire Organization”. We cannot assign Public Groups to profiles.
Another related concept that Salesforce defines is Public group. Public group consists of users, roles or "roles and subordinates".
Sharing rule is defined using public groups. Record that match certain condition can be assigned to users in public groups using Sharing Rules. Sharing rules functionality is available via the menu Sharing Settings.
Manual Sharing is used to grant one-off access. Manual sharing can be granted by record owner, any one above the owner in role hierarchy and System Administrator. Manual sharing is used to handle exception cases where access to a particular record needs to be given to a specific user. There is a Sharing button on the records page. This is used to provide manual sharing. The Ownership of the record can be transferred to any user who has at least Read permission on the record.
If the Read permission for the object is revoked from the users profile, the user will not be able to see their own record.
Full access to the records means user can View, Edit, Transfer Ownership, Delete and Share the record. Full access is granted to:
- Record Owner
- Users above record owner in role hierarchy.
- Users with “Modify All Data “ permission i.e. Admin
Apex Sharing Reasons can have upto 10 Apex Sharing Reasons. It can only be given for Custom Objects.

Salesforce Sites

User Interface can be private (internal Salesforce users) or public. Public interfaces are provided to anonymous users using Sites - anyone could access a website built on Sites without having a Salesforce login.
If Sites is licensed, the functionality of Sites is available at Develop-->Sites.
A sites user has a unique domain name. One domain name can be used to support multiple websites. Example domain name could be - http://ap1.mydomain.salesforce.com/siteName . The domain name must be unique among all site users and can represent the organization's name.
Creation of sites requires specifying fields like Site label, Site Name, Site contact, Default web address, active site home page, inactive site home page.
Once an organization has registered a domain name with a domain name registrar, it can point the url to sites url.
Site template is a VisualForce page that defines the default look-and-feel of the sites page.
Force.com sites are
1. Public, unauthenticated websites
2. Accessed from branded domain names
3. Build with VF pages
4. From data and content in a Salesforce application
Creating a Force.com Site requires performing the following steps
1. Build a Force.com App
2. Design your web interface in visual force
3. Create a Force.com site
4. Activate the Force.com site
Key concepts about Force.com Sites security

Security for your site is controlled through public Access Settings
Access can also be restricted by specifying an IP range.

VisualForce

SalesForce provides two ways to build user interfaces. These are Page Builder and VisualForce. PageBuilder automatically generates pages with default look-and-feel. VisualForce allows developers to define their own user interface.
VisualForce plays the role of JSP or ASP in SalesForce. It is used to develop user interface for SalesForce applications.
Standard tags are included in VisualForce using apex keyword. As an example the top level tag in VisualForce is <apex:page>.Rest of the code is included in <apex:page>. Custom tags use tags use the prefix c:.
The syntax to access fields in VisualForce is {!object.Field}. The expression in between {!} is evaluated. $User gives the details of the user that is logged in. {!$User.FirstName} displays the first name of the logged in user.
A VisualForce page contains HTML, VisualForce components, JavaScript, Flash and text. All elements need to be well-formed. Visual Force gets converted into HTML at the server.
VisualForce can be used to support other devices like phones, PDAs.
<apex:inputfield value="{!account.name}"/> generates an input element. Based upon the data type of account,name field, appropriate user interface element is displayed (such as text box, pick list). This is an example of data binding. The value of the name field is displayed in the user interface, and changes are saved back to the object.
<apex:form> is used to display a form. Other VisualForce display elements like text box, checkbox are included in a form.
<apex:detail/> is used to print the details page for an object. If the attribute "relatedlist" is set to false, then related lists are not displayed. Specific related lists can be added using the VisualForce component <apex:relatedlist>
VisualForce supports development mode. Development mode can be enabled using Setup|My Personal Information}Personal Information. In development mode, VisualForce provides two main features.
1. Split screen development: In this the browser window is divided into two parts. The bottom part is used to show VisualForce code. Changes can be saved and resulting page is displayed on the same browser window.
2. Creation of new pages by just typing the URL www.servername.com/apex/PageName where servername is the SalesForce server that is allocated to you.
Page layouts support one or two columns. VisualForce can support more than two columns.
Previous version of VisualForce is S-controls. It is now being phased out. Visual force two advantages over S-control
1. Visual force having much better performance as compared to S - control.
2. Visual force is a tag Markup language and S - controls are a javascript procedural code language.
VisualForce components and pages have version numbers. SalesForce stores the version numbers along with pages. All older versions are supported.
VisualForce elements take attributes similar to XML format. As an example in the statement below, sidebars and top headers are not displayed.
<apex:page showHeader="false"> </apex:page>
<apex:page> also takes an attribute renderAs as input which supports pdf generation.
Record's id is sent via request parameter, and made available to the page. In the above example the id identifies the account for which name has to be displayed.
VisualForce consists of three type of elements
1. VisualForce pages: These are used to define the user interface. VisualForce pages support multiple devices
2. VisualForce components: Standard prebuilt or custom user interface components available through a tag library
3. VisualForce controllers:
There are three type of controllers -

Standard Controller

The standard controllers provide access to standard Salesforce.com behavior.<:apex:page standardController="Account"> They are available for all API entities/objects, such as Account, Contact, Opportunity etc as well as custom objects. They Provide access to standard Salesforce data and behavior - Standard object record data and Standard actions like save, edit , delete.

Custom Controller

Custom Controllers is used for custom behavior or non-standard data-sets.<:apex:page controller="MyAccount"> They can be used to create wizards or leverage call outs.

Controller Extensions

Controller Extensions extend the behavior of standard controllers.<:apex:page standardController="Contact" extensions="ClassA, ClassB"> They are used to add custom behaviour or additional data to controllers

Static resources are accessible through global variables $Resource. It can be used to access CSS stylesheets, images, flash movies and JavaScript libraries.

Error messages are displayed in pageMessages component and can be displayed by the statement <apex:pageMessages/>

To perform the save operation, the save() method can be invoked on the object. This is an example of action binding. <apex:commandButton value="Save" action={!save}"/>

The look-and-feel of VisualForce is managed using StyleSheets. Default SalesForce look-and-feel can be changed.

The size of VisualForce page cannot be more than 15MB.

Web Services can also be invoked from VisualForce.

Layout Editors

Layout editor provides a drag-and-drop interface to define the user interface. Using Layout editor, fields of a page can be moved around, sections and space can be added.

Layout editor supports one-column and two-column layout.

Double-clicking on a field allows fields to be made read-only and required.

Salesforce Easy Learn

Saturday 17 December 2011

Salesforce Tutorial for certification(Developer 401)