Sunteți pe pagina 1din 14

MODULE - 4

System Logs :

The System Log console is a separate window that displays debugging information, as well
as its cumulative limits and source code. It can be considered a context-sensitive execution
viewer, showing the source of an operation, what triggered that operation, and what
occurred afterward. Use the System Log console to view debug logs that include database
events, Apex processing, workflow, and validation logic. The System Log is used to view
debug logs of currently logged in users of the organization. Access the SystemLog console
fromthe Salesforce.comuser interface by clicking Your Name | System Log in the upper right
corner of any page.

To revert to the old version of the SystemLog console, click Switch to old System Log.

The SystemLog console is made up of the following sections:
Text entry box
List of existing debug logs
Stack trace and back trace
Execution log
Source window
Executed units and Limits

Text entry box:
To enter Apex code snippets into the SystemLog console for debugging

List of existing debug logs:
You can filter which logs are displayed in the list of debug logs.
Auto Hide Logsthe next time the page is refreshed, hide the list of logs. This button is
a toggle: click the button a second time to display all logs again.
Log Levelsspecify the logging levels for future requests.
Clearremoves all logs fromthe list of logs in the SystemLog console. If you are
monitoring debug logs for a user, those logs are still accessible fromthe Debug Log page.
Click Your Name | Setup | Monitoring | Debug Logs.
This Session Onlyonly display logs generated since opening the SystemLog console.
Filterdisplays items that match what is entered. For example, if you are monitoring
more than one user's debug log, type in that user's name to display only those logs. The
search is case sensitive.

Stack trace and back trace:
The stack section displays a tree-structure of all the top level items in the process. Use this to
see the hierarchy of items as they are called in the process. For example, if a class calls a
second class, the second class is displayed as a child node of the first class.
The stack section displays information top downfrominitiating calls to the next level.
The back trace (the window below the stack trace) contains information bottomupthe
lowest level call is listed first, followed by the itemthat called it, and so on.

Each item in the back trace has the following information:
Column Description
Scope Delimited region within the process, such as workflow, a class, DML, and so on
Unit Name of the item(region)
Duration Amount of time (in milliseconds) the itemtook to run
Heap Amount of heap (in bytes) the itemused

Execution log:
The execution log section contains the debug log for the process. The debug log contains every
action that occurred in the process, such as method calls, workflow rules, DML operations, and so
on.

Source window:
The source section contains the executed source code or the metadata definitions of entities used
during the process. What is displayed in the source section depends on what is selected elsewhere
in the SystemLog console. The source section also lists how many times a line of code was
executed.

Executed units and Limits:
Use the executed units section to examine which items in the process used the most system
resources. Use the Limits tab to track the resources used by the process. The limits are listed by
name and amount.
To filter out the information displayed on the Executed Limits tab by the type of item, click the
button for that type, for example, to no longer view methods in the section, click Methods. Click
the button a second time to display methods again.
Right click the down-arrow on any column header to sort the information in the column. You can
also select which columns you want displayed in the executed units section.

Debug logs:

You can retain and manage the debug logs for specific users.
To view the details of a debug log, click Your Name | Setup | Monitoring | Debug Logs, and
then click View next to the debug log you want to examine. Click Download to download the log
as an XML file.
The debug log contains information about the transaction, such as if it was successful, the size of
the log (in bytes), how long the transaction took in milliseconds, and so on. The log itself contains
additional information about the transaction, depending on the filters set for the user.
The following points to remember for the debug log:
Once user added to the log can record upto 20 debug logs after that click reset for the
next 20. Previous 20 are not overridden.
Each debug log can be upto 2MB.
Each organization can retain upto 50MB debug log. Once organization reached 50MB
debug logs most older starts overwriting.

Auditing:

Auditing features do not secure your organization by themselves, but these features provide
information about usage of the system, which can be critical in diagnosing potential or real
security issues. It is important that someone in your organization performregular audits to detect
potential abuse. The other security features provided by Salesforce.comare preventative. To
verify that your system is actually secure, you should perform audits to monitor for
unexpected changes or usage trends.
Auditing features include:
Record Modification Fields
All objects include fields to store the name of the user who created the record and who
last modified the record. This provides some basic auditing information.
Login History
You can review a list of successful and failed login attempts to your organization for the
past six months.
Field History Tracking
You can also enable auditing for individual fields, which will automatically track any
changes in the values of selected fields. Although auditing is available for all custom
objects, only some standard objects allow field-level auditing.
Setup Audit Trail
The setup audit trail history helps you track the recent setup changes that you and other
administrators have made to your organization. This can be especially useful in
organizations with multiple administrators.
To view the setup audit trail history, click Your Name | Setup | Security Controls | View
Setup Audit Trail. To download your organizations full setup history for the past 180
days, click the Download link.
The setup audit trail history shows you the 20 most recent setup changes made to your
organization. It lists the date of the change, who made it, and what the change was.

Field History Tracking:

You can select certain standard and customfields to track on the History related list of accounts,
cases, contacts, contracts, leads, opportunities, solutions, and customobjects. Modifying any of
these standard or customfields adds a new entry to the History related list. All entries include the
date, time, nature of the change, and who made the change. History data does not count against
your organizations storage limit. Note that not all fields types are available for history tracking.
Tracking Field History for Standard Objects
You can track field history for Accounts, Cases, Contacts, Entitlements, Service
contracts, Contract line items, Contracts, Leads, Opportunities, Solutions.
You can select a combination of up to 20 standard and customfields per object.
For LONG TEXT AREA and MULTI-SELECT PICKLIST the new values and old
values are not noted. They are tracked as edited.
You cannot track the following fields:
History of formula, roll-up summary, or auto-number
Created By and Last Modified By
Expected Revenue field on opportunities
Master Solution Title or the Master Solution Details fields on solutions; these fields
display only for translated solutions in organizations with multilingual solutions enabled.

Console Tab:

The console is a tab that combines a list view and related records into one screen with
different frames so that users have all the information they need when interacting with
Salesforce. By using 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.

How is the Console tab different fromother tabs in Salesforce?

The Console tab is just like other tabs in Salesforce except that the console can display
records fromseveral different Salesforce tabs all on one Console tab. This allows you to
have all the information you need on one tab when interacting with Salesforce.

What components make up the console?

The Console tab contains four components viewed by users: the list view, detail view,
mini view, and sidebar. Administrators customize what displays on the console's list
view, detail view, and mini view by configuring console layouts, related objects, and
mini page layouts.

How do I view the console?
You can view the console by clicking the Console tab. You can only access the Console tab if
your administrator has assigned your user profile to a console layout and set your Console tab
visibility setting to either Default On or Tab Hidden. If your Console tab
visibility setting is set to Tab Hidden, then you can customize your display to see the
Console tab.

Can I view more than one Console tab?

No. You can only view one Console tab. However, your administrator can customize
many different console layouts to display a variety of objects in the console's list view,
and then assign those console layouts to different user profiles to satisfy business needs
for different users.

Can I create list views fromwithin the console?

No. The list views you can select to display in the Console tab are the same list views
defined on the tabs of other objects. You cannot create a list view within the console.

Is the console the same thing as the Service Cloud console?

No.
-The Service Cloud console improves on the Console tab by letting you:
-Work with fewer clicks and less scrolling.
-Limit switching between pages.
-Easily spot important fields on records.
-See records and their related items as tabs on one screen so that you never lose context
or navigate too far froma record.
-J ot notes on each record in an interaction log.

Tagging:

Tags are words or short phrases that you can associate with most Salesforce records to describe
and organize their data in a personalized way. Use tags to group records fromvarious objects by
a common topic or use, and then use those tags in search to make finding information fast and
intuitive.

For example, if you met a number of contacts and leads at a conference, you might tag themall
with the phrase User Conference 2011. You could then search for the User Conference 2011 tag
and click that tag in search results to retrieve those records.

Salesforce supports two types of tags:

Personal tags are private. Only you can view any personal tags that you add to a record.

Public tags are shared among all users in an organization. Any user with access to the
record can view the public tags that you add.

Administrators can enable personal and public tags for accounts, activities, assets, campaigns,
cases, contacts, contracts, dashboards, documents, events, leads, notes, opportunities, reports,
solutions, tasks, and any customobjects

In the Personal Tags or Public Tags text boxes, enter comma-separated lists of the tags that you
want to associate with the record. Tags can only contain letters, numbers, spaces, dashes, and
underscores, and must contain at least one letter or number.

Limits :

You can have a maximumof:
500 unique personal tags
5,000 instances of personal tags applied to records

Across all users, your organization can have a maximumof:
1,000 unique public tags
50,000 instances of public tags applied to records
5,000,000 instances of personal and public tags applied to records
Analytic Snapshots:

An analytic snapshot lets you report on historical data. Authorized users can save tabular or
summary report results to fields on a custom object, then map those fields to corresponding
fields on a target object. They can then schedule when to run the report to load the custom
object's fields with the report's data. Analytic snapshots let you to work with report data similarly
to how you work with other records in Salesforce.
For example, a customer support manager could set up an analytic snapshot that reports on the
open cases assigned to his or her teameveryday at 5:00 PM, and store that data in a customobject
to build a history on open cases fromwhich he or she could spot trends via reports. Then the
customer support manager could report on point-in-time or trend data stored in the customobject
and use the report as a source for a dashboard component.
The following terminology is used for analytic snapshots:
Analytic Snapshot Source Report
The custom report scheduled to run and load data as records into a customobject.

Analytic Snapshot Target Object
The custom object that receives the results of the source report as records.

Analytic Snapshot Running User
The user whose security settings determine the source report's level of access to data. This
bypasses all security settings, giving all users who can view the results of the source report in the
target object access to data they might not be able to see otherwise.
Be aware of the type of license your Running User has. For example, if the Running User of
an analytic snapshot has a Salesforce license, users who have Force.comPlatformor Salesforce
PlatformOne licenseswill not be able to view it. Alternatively, if the Running User has
a Force.comPlatformor Salesforce PlatformOne license, users who have Salesforce licenses will
be able to see the analytic snapshot. If you have users with Force.comPlatformor Salesforce
PlatformOne licenses, we recommend creating a separate analytic snapshot for themwith
a Running User that has a Force.comPlatformor Salesforce PlatformOne user license.

To set up an analytic snapshot:
1. Create a Source Report includes the fields to load as records into a target object.
2. Create a target object in which to store the records loaded fromthe source report.
3. Create fields on the target object that will receive the source report's results when
the analytic snapshot runs.
4. Define the analytic snapshot by name, description, running user, source report, and target
object.
5. Map Specific Fields on the source report to specific fields on the target object.
6. Schedule the analytic snapshot to run.
An analytic snapshot will fail during a scheduled run if:
The source report includes more than 100 fields
The source report was changed fromsummary to tabular
The selected grouping level for a summary source report is no longer valid
The running user does not have access to the source report
The running user does not have the Run Reports permission
The target object has more than 100 customfields
The target object contains validation rules
The target object is included in a workflow
The target object is a detail object in a master-detail relationship
The target object runs an Apex trigger when new records are created on it
The running user does not have the Create permission on the target object. Note that if
the target object's status is In Development, the running user must have the Customize
Applications permission.
Reports:
Note: See the videos present in this links below:
https://ap1.salesforce.com/help/doc/en/reports_builder_editing.htm http://vimeo.com/4303291
A report returns a set of records that meets certain criteria, and displays it in organized rows and
columns. Report data can be filtered, grouped, and displayed graphically as a chart.Reports are
stored in folders, which control who has access. You must have Read permission on the records
included in your reports; otherwise, when you run them, they may be missing data or appear
blank. Reports are summaries of the data that's stored in an app. They consist primarily of a table
of data, but can also includedata filters, groupings, and a customized graph.
Salesforce supports three report formats, each with varying degrees of functionality and
complexity:
Tabular reports: Tabular reports are the simplest and fastest way to look at your data. Similar
to a spreadsheet, they consist simply of an ordered set of fields in columns, with each matching
record listed in a row. While easy to set up, they can't be used to create groups of data or graphs.
Consequently, they're best used just for tasks such as generating a mailing list.
Tip: Use tabular reports when you want a simple list or a list of items with a grand total.
Summary reports: Summary reports are similar to tabular reports, except that they also allow
you to group rows of data, view subtotals, and create graphs. For example, in the sample
Employee Interviewer Introducing reports that appear in the following screenshot, the summary
report groups the rows of reviews by the possible values of the Owner Name field, allowing us to
see at a glance subtotals of how many times the two interviewers have talked to candidates and
entered reviews for them. While a little more time-consuming to set up, summary reports give us
many more options for manipulating and organizing the data, and, unlike tabular reports, they can
be used in dashboards. Summary reports are the workhorses of reportingyou'll find that most of
your reports tend to be of this format.
Tip: Use summary reports when you want subtotals based on the value of a particular field or
when you want to create a hierarchical list, such as sales organized by year and then by quarter.
Matrix reports: Matrix reports are the most complex kind of report available, allowing you to
group records both by row and by column. For example, Employee Interviewer reports, the
matrix report groups the review rows by the possible values of the Owner Name field, and also
breaks out the possible values of the Position field into columns. Consequently, the report gives
us subtotals for the number of times an interviewer has interviewed candidates and entered
reviews for a particular position. These reports are the most time-consuming to set up, but they
also provide the most detailed view of our data. Like summary reports, matrix reports can be used
in dashboards.
Tip: Use matrix reports when you want to see data by two different dimensions that aren't related,
such as date and product.
Note: You should be very clear about which report to use according to the situation and for
further information on reports you can refer fundamentals pdf.
DashBoards :
A dashboard is a group of different summary or matrix report charts that graphically
display customreport data.
We can select up to 20 different customreports to display in each dashboard, and we can
arrange them in two- or three-column layouts.
Users can browse through all of the dashboards that are available in the Company
Dashboards folder in their
organization and can also select a favorite dashboard that always displays on the Home
tab when logging in.
Components come in five varieties:
ChartsDisplays a pie chart, bar chart, line chart, or any other type of chart that can be made in
a report.
TablesDisplays a two-column table that contains record counts and values fromthe top-level
row grouping in the
report.
MetricsInserts the grand total of a report at the end of a label that you customize.

GaugesUses the grand total of a report as a point on a scale.
CustomS-ControlsDisplays any customcontent that can be viewed in a Web browser, such
as an ActiveX control, an Excel file, or a customHTML Web form.
Custom Report Types:
Customreport types define the report criteria fromwhich your users can run and create custom
reports. When you create a customreport type, you specify the objects, relationships, and fields
that users can select for their reports.

How are customreport types useful in our Recruiting app? Well, our recruiters will appreciate
it if we give them an easy way to scan for positions to which candidates have applied. In addition,
the recruiters will probably want to see which of those job applications have reviews. That way,
they'll know if any positions are on the verge of closing.

Users with the Manage CustomReport Types permission can view and define customreport
types that include objects they do not have permission to access. However, they cannot access
data stored in those objects. For example, a user with the Manage CustomReport Types
permission who does not have permission to view leads can view and define customreport types
that include leads, but he or she cannot access lead data. This enables specific users to build
report types for all users in their organization without compromising data security settings.

After you save a customreport type, you can't change the primary object associated with it. If you
want to change the primary object, you must define a new customreport type.

Customreport types have some limits on the number of items included:
A customreport type can fetch objects in three levels of related lists away fromthe
primary object, giving four related objects, such as Accounts, Contacts, Opportunities,
and Opportunity Products.
A customreport type can contain fields available via lookup through four levels of
lookup relationships. For example, for an account, you can get the account owner, the
account owner's manager, the manager's role, and that role's parent role.
A customreport type can contain up to 60 object references. These objects can be used
as the main four objects, as sources of fields via lookup, or as objects used to traverse
relationships. Each referenced object counts toward the maximumlimit even if no fields
are chosen fromit. For example, if you do a lookup fromaccount to account owner to
account owners role, but select no fields fromaccount owner, all the referenced objects
still count toward the limit of 60.
You can add up to 1000 fields to each customreport type. A counter at the top of the
Page Layout step shows the current number of fields included. If you have too many
fields, you cannot save the layout.


Note:
See the Link below for more details about customreport:
https://ap1.salesforce.com/help/doc/en/reports_report_type_setup.htm
Data Loader :
The Data Loader is a client application for the bulk import or export of data. Use it to insert,
update, delete, or export Salesforce records. When importing data, the Data Loader reads,
extracts, and loads data fromcomma separated values (CSV) files or froma database connection.
When exporting data, it outputs CSV files.
You can use Data Loader interactively through its user interface, or set up automated batch
processes launched from the command line. When you use the user interface, you work
interactively to specify the configuration parameters, CSV files used for import and export, and
the field mappings that map the field names in your import file with the field names in Salesforce.
When you set up batch processes through the command line, you specify the configuration, data
sources, mappings, and actions in files used for automated processing.Availavle in
Enterprise, Unlimited, and Developer Editions. To access page to download data loader user
needs Modify All Data Permission. To use data loader you require appropriate user
permission for the operation you are doing, for example, Create on accounts to insert new
accounts.

The Data Loader offers the following key features:
An easy-to-use wizard interface for interactive use
An alternate command line interface for automated batch operations
Support for large files with up to 5 million records
Drag-and-drop field mapping
Support for all objects, including customobjects
Detailed success and error log files in CSV format
A built-in CSV file viewer
Support for Windows 7 and Windows XP
When to use data loader:
You need to load 50,000 to 5,000,000 records. If you need to load more than 5,000,000
records, we recommend you work with a Salesforce.compartner.
You need to load into an object that is not yet supported by web-based importing.
You want to schedule regular data loads, such as nightly imports.
You want to export your data for backup purposes.
Import wizard :
We can use Import wizard for all custom objects and some standard objects (Solution, Lead,
Account and Contact).
Will the import wizard prevent duplicate records?
The salesforce.com import wizard will de-duplicate records based on the spelling of the
account and contact name. When importing a record, if there is an existing account or
contact (either previously there or created earlier in the import process), the import
wizard will attempt to update the existing record. Note that unless you select the
"overwrite existing account values" checkbox, the import wizard will not overwrite any
existing information. In other words, it will update any empty fields without overwriting
the current data.

When to use Web-based importing:
You are loading less or equal to 50,000 records.
The object you need to import is supported by the web-based import wizards.
You want to prevent duplicates by uploading records according to account name and site,
contact email address, or lead email address.
Note :See the Link below for more details about Import Wizard:
https://ap1.salesforce.com/help/doc/en/importing.htm
External Id :
When importing customobjects, solutions, or person accounts, you can use external IDs to
prevent duplicate records frombeing created as a result of the import operation.
An external ID is a customfield that has the External ID attribute, meaning that it contains
unique record identifiers froma systemoutside of Salesforce. When you select this option, the
import wizard will detect existing records in Salesforce that have the same external ID. Note that
this operation is not case-sensitive - for example, ABC will be matched with abc. However,
there is an exception: if the customfield has the separate Unique attribute and the case-
sensitive option for that attribute is selected, uppercase and lowercase letters will not be
considered identical.

How many External ID's can each object / entity have?
External ID Attribute on CustomFields. In the Salesforce CRM user interface, you can identify
up to three (3) customfields on an object as being an external ID field. The field type must be a
text, number, or email field. An external ID contains record IDs froma systemoutside 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.

What is the difference between External ID and Unique ID?
External ID
This is a field that usually references an ID fromanother (external) system. For instance, if the
customer has an Oracle Financials systemthat they will be linking with salesforce.com, it may be
easier for themto be able to refer to the Oracle ID of account records fromwithin salesforce. So
they would create an external ID in salesforce.comand they would load the Oracle ID into that
field for each account. They can then refer to that ID field, rather than the salesforce.comid.

Additionally, if you have an external ID field, the field becomes searchable in the sidebar search.
You also can use the upsert API call with the external ID to refer to records.

You can have multiple records with the same external ID (though it is not recommended, as it
will defeat the purpose of the external id)

Unique ID field
This is a setting for the field that will prevent you fromusing the same value in multiple records
for the unique field. So if I create a 5 character text field and make it unique, and I create a record
with the value "12345" i will not be able to create another record with that same value in the
unique field. If i try to do so, I will get an error saying that the value is already in use.

Often, External Ids are set with the unique property so that the IDs will be unique to each record.

Are options like Required, Unique, External ID available on standard fields?
You cannot enable Required, Unique, External ID on standard fields in the same manner as
customfields. As a workaround you can create a duplicate customfield and hide the standard
field in the record type.

Force.com Sites :

Force.comsites are available in: Developer, Enterprise, and Unlimited Editions
.Salesforce organizations contain valuable information about partners, solutions, products, users,
ideas, and other business data. Some of this information would be useful to people outside your
organization, but only users with the right access and permissions can view and use it. In the past,
to make this data available to the general public, you had to set up a Web server, create custom
Web pages (J SP, PHP, or other), and performAPI integration between your site and your
organization. Additionally, if you wanted to collect information using a Web form, you had to
programyour pages to performdata validation.
With Force.comsites, you no longer have to do any of those things. Force.com sites enables you
to create public websites and applications that are directly integrated with your
Salesforce organizationwithout requiring users to log in with a username and password. You
can publicly expose any information stored in your organization through a branded URL of your
choice. You can also make the site's pages match the look and feel of your company's
brand. Because sites are hosted on Force.comservers, there are no data integration issues. And
because sites are built on native Visualforce pages, data validation on collected information is
performed automatically. You can also enable users to register for or log in to an associated portal
seamlessly fromyour public site.

The following examples illustrate a few ways that you can use sites:
Create an ideas siteUse sites to host a public community forumfor sharing and voting
on ideas about your company, services, or products. Ideas websites can be made public
using sites.
Publish a support FAQProvide helpful information on a public website where
customers can search for solutions to their issues.
Create a store locator toolAdd a public tool to your portal that helps customers find
stores in their area.
Publish an employee directoryAdd an employee directory to your company's intranet
by creating a site restricted by IP range.
Create a recruiting websitePost job openings to a public site and allow visitors to
submit applications and resumes online.
Publish a catalog of productsList all of your company's products on a public website,
with model numbers, current prices, and product images pulled dynamically fromyour
organization.
Force.comDomain:
Your Force.comdomain name is used for all the sites that you create. For example, your
company could create one public site for partners, another for developers, and a third for support.
If your company's domain is http://www.mycompany.force.com, those three sites might have the
following URLs:
http://mycompany.force.com/partners
http://mycompany.force.com/developers
http://mycompany.force.com/support
Note : See the Link below for more details about Force.comsites :
https://ap1.salesforce.com/help/doc/en/sites_considerations.htm

S-ar putea să vă placă și