SFDC Notes

Dev401 Certification- Points to Remember
Study Guide for Certification Topics Covered in an Order
This covers the topics to the depth which is covered from Help & Training Centre
Prepared By Pramod Kumar. V
Standard Objects:
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
To set up field history tracking: 1. 2. 3. Click Your Name | Setup | Customize and select the object you want to configure. Click Fields. Click Set History Tracking.
For accounts, contacts, leads, and opportunities, select the Enable Account History, Enable Contact
History, Enable Lead History, or Enable Opportunity Field History checkbox. Deselect the checkbox if you do not want to track any changes. If you deselect the checkbox, the History related list is automatically removed from associated page layouts. This checkbox is not available for cases, solutions, or contracts because you cannot disable their history tracking. Certain changes, such as case escalation, are always tracked.
When you choose the fields you want to track, Salesforce begins tracking history from that date and time forward.
Changes made before that date and time are not included. Note that some case, solution, and contract fields are preselected for history tracking, so changes to those fields are automatically tracked from the time your organization began using Salesforce. 4. 5. Choose the fields you want tracked. Click Save.
History Tracking Implementation Tips Administration
You can select a combination of up to 20 standard and custom fields per object. You cannot track the following fields:
o o o o
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.
If you use both business accounts and person accounts, review the following before enabling account field history tracking:
Field history tracking for accounts affects both business accounts and person accounts.
o o o
A maximum of 20 account fields can be tracked. This limit includes fields on person accounts and business accounts. Enabling field history tracking on person accounts does not enable field history tracking on personal contacts. To report on person account history, run the Account History report.
You can report on activated contracts whose fields are tracked by clicking New Custom Report on the Reports tab, selecting Contract Reports as the data type, and choosing Contract History. If you disable field history tracking on an object, you can still report on its history data up to the date and time you disabled tracking. You cannot disable field history tracking for an object if a field on the object is referenced in an Apex script. For more information, see Force.com Apex Code Overview. If the parent record in a lookup relationship is deleted, the field history tracking for the child record does not record the deletion. For example, if a parent account is deleted, the Account History related list for the child account does not show the deletion.
Customization
When you enable history tracking for an object, be sure to customize your page layouts to include the object's history related list. For more information, see Customizing Page Layouts. You cannot customize which opportunity fields are tracked in the opportunities' Stage History related list; however, you can choose which opportunity fields are tracked in the Opportunity Field History related list. You cannot customize the History related list because it does not store data. The History related list links to data stored elsewhere. When you delete a custom field, all of the field history data is deleted and changes are no longer tracked. If you disable field history tracking on a custom object, then you cannot report on its field history.
Management
Changes to fields with more than 255 characters are tracked as edited, and their old and new values are not recorded. For example, changes to long text area fields are tracked as edited. Tracked field values are not automatically translated; they display in the language in which they were made. For example, if a field value is changed from Green to Verde, Verde is displayed no matter what a user's language is, unless the field value has been translated into other languages via the Translation Workbench. This also applies to record types and picklist values.
Changes to date fields, number fields, and standard field labels are shown in the locale of the user viewing the History related list. For example, a date change to August 8, 2005 shows as 8/5/2005 for a user with the English (United States) locale and as 5/8/2005 for a user with the English (United Kingdom) locale.
Changes to custom field labels that have been translated via the Translation Workbench are shown in the locale of the user viewing the History related list. For example, if a custom field label is Red and translated into Spanish as Rojo, then a user with a Spanish locale will see the custom field label as Rojo. Otherwise, the user will see the custom field label as Red.
Changes to the Amount and Quantity fields on opportunities are tracked even when the field is updated as the result of a change to an opportunity's products or schedules. Changes to the Closed When Created field on cases are only tracked when the field is updated via the Force.com API. Field updates are tracked in the History related list if you have set history tracking on those fields
How to rename Standard Tabs, Objects, and Fields activation for customers? The ability to change the display labels of tabs, objects, fields, and other related user interface labels is automatically enabled for all Professional, Enterprise, Unlimited, and Developer Edition . To rename tabs and labels, click
Setup | Customize | Tab Names and Labels | Rename Tabs and Labels.
For more information, see "Renaming Tab and Field Labels" in the SalesForce online help.
Step 1: Go to Set up | Customize | Tab Names and Labels | Rename Tab and labels
Step 2: Choose the object that you would like to edit | click Edit
Step 3: On this screen is where you have the option to change the label of the object
Step 4: Here is where you can rename labels for fields that are associated with the object that you wish to rename -------------------------------------------------------------------------------------------Here are some considerations involving renaming standard fields and tabs: Renaming salesforce.com 's standard application terminology will have some implications on your salesforce.com administration and your users experience on the application especially in the areas of help, training, support, and release communications. Salesforce.com wants to make sure you are aware of this before we activate the feature for your organization. Please review the information below in detail. If you are ready to move ahead with this feature, please follow the instructions at the end of this message. Which standard application terminology can be renamed? - Only the following standard tabs and objects can be renamed: Accounts, Activities, Assets, Campaigns, Cases, Contacts, Contracts, Documents, Events, Ideas, Leads, Opportunities, Opportunity Products, Partners, Price Books, Products, Solutions and Tasks. NOTE: You cannot rename the Forecasts tab. Where will the new tab, object, and field names show up within the application? - All salesforce.com pages accessible by your end users, including Personal Setup pages, will automatically reflect the new terminology you define, i.e. all labels and sentences on these pages will be automatically reconstructed to reflect your new terminology. For example, if you rename Accounts to Companies, all references to "accounts" will be changed automatically to "companies". NOTE: That all Administrator Setup pages will continue to use standard salesforce.com names even if you change them. What impact does a renaming standard object have on the administration of salesforce.com? - Renaming standard names will create some additional administrative work for salesforce.com administrators. * The standard list views on every salesforce.com tab will continue to use the standard object names even if you change them. You will need to rename each manually. * Titles and descriptions of all standard reports will continue to use the standard object names even if you change them. * Titles and descriptions of all standard email templates will continue to use the standard object names even if you change. * Any customizations you previously implemented where you used the standard salesforce.com terminology will have to be manually changed. This includes but is not limited to custom fields, page layouts, record types, views, reports, and communication templates. For example, if you already have a custom email template titled "Account Health Check," you will have to change it to "Company Health Check" to reflect your new terminology.
TRANSLATION WORKBENCH:
The Translation Workbench lets you specify languages you want to translate, assign translators to languages, create translations for customizations youve made to your Salesforce organization, and override labels and translations from managed packages. Everything from custom picklist values to custom fields can be translated so your global users can use all of SalesForce in their language. When a customized component is translated, changes to that component are tracked and the Out of Date indicator is set when the translations need updating. You can manage translated values for any ofSalesforce supported languages.
Note: Custom objects are not available in the translation workbench. Use the rename tabs and
labels interface or the IDE for custom object translation.

Setting Up the Translation Workbench Available in:
Professional, Enterprise, Unlimited, and Developer Editions
User Permissions Needed
To add or edit languages:
Manage Translation
To assign translators:
Manage Translation
To export or import translation files To translate terms:
Manage Translation
Users must be assigned to a profile that has View Setup and Configuration AND Be designated as a translator
To override terms:
Users must be assigned to a profile that has View Setup and Configuration AND Customize Application
Enabling the Translation Workbench makes some changes to your Salesforce organization:
Picklist values must be edited individually. This means you cant mass edit existing picklist values, though you can still mass add new values. When picklist values are sorted alphabetically, the values are alphabetical by the organization's default language. Reports have a Language drop down on the filter criteria page when any filter criteria uses the "starts with", "contains", or "does not contain" operators. Import files have a Language drop down and all records and values within the import file must be in that language. Web-to-Lead and Web-to-Case have a Language drop down before you generate the HTML.
Note: Salesforce assumes all customizations are entered in the organization's default languageglobal administrators should work together in the organization's default language.
To enable the Translation Workbench: 1. 2. Click Your Name | Setup | Translation Workbench | Translation Settings. On the welcome page, click Enable. Note The Manage Translation permission is enabled by default in the System Administrator profile and can only be edited in a custom profile. If you'd like only certain administrators to enable, disable, or manage the Translation
Workbench, you must create a new profile cloned from the System Administrator profile, disable the Manage Translation permission, and assign those administrators you don't want managing the Translation Workbench to the new profile. To disable the Translation Workbench, click Your Name | Setup | Translation Workbench | Translation Settings | Disable.Note In a Developer organization with a managed package containing translations, once the Translation Workbench is enabled, it can't be disabled.
Tags Overview Available in:
All Editions
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 from various objects by a common topic or use, and then use those tags in search to make finding information fast and intuitive.
User Conference 2011. You could then search for the User Conference 2011 tag and click that tag in search results to
For example, if you met a number of contacts and leads at a conference, you might tag them all with the phrase 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 custom objects (except relationship group members), allowing you to:
Tag records Remove tags from a record Browse, search, and manage tags
Enabling Tags Tag settings available in:
All Editions
To modify tag settings:
Customize Application
1. 2. 3.
Click Your Name | Setup | Customize | Tags | Tag Settings. Select Enable Personal Tags and Enable Public Tags to allow users to add personal and public tags to records. Deselect both options to disable tags. Specify which objects and page layouts should display tags in a tag section at the top of record detail pages. The tag section is the only way that a user can add tags to a record. For example, if you only select account page layouts, users in your organization can only tag account records. Additionally, if you only select account page layouts for personal tags and not public tags, users can only tag account records with personal tags.
4.
Click Save.
Use these tips when enabling tags.
When you enable tags, you can also add them to a page layout by editing the page layout directly. See Customizing Page Layouts. Search results and the Tags page don't display custom objects that don't have an associated tab, even if tags are enabled for the custom object. If you want custom object records to appear in search results or on the Tags page, you must create an associated tab. The tab doesn't have to be visible to users. Customer Portal users can't view the tags section of a page, even if it is included in a page layout.
Tagging Records Available in:
All Editions
To edit tags on a record:
Read on the record
1. 2.
On the top right corner of the record detail page, click click Edit Tags.
Add Tags. If the record already has associated tags,
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. As you enter new tags, up to 10 tags that have already been defined are displayed as auto-complete suggestions. As you type, the list of suggestions changes to show only those tags that match the prefix you have entered. To choose a suggestion, click it or use your keyboard arrow keys to select it and press the TAB or ENTER key.
3.
Click Save.Tip When you create or edit tags, you can press the ENTER key to save your changes or the ESC key to discard them.
Note You and your organization are subject to limits on the number of personal and public tags that you can create and apply to records. If you attempt to tag a record with a new tag that exceeds one or more of these limits, the tag isn't saved. If this occurs, you can delete infrequently used tags from the Tags page. See Browsing, Searching, and Managing Tags.
Removing Tags from Records Available in:
All Editions
To edit tags on a record:
Read on the record
Edit Tags. 2. Next to the Personal Tags or Public Tags text boxes, click [X] next to the tag that you want to remove. 3. Click Save.Tip
1. On the top right corner of the record detail page, click
When you create or edit tags, you can press the ENTER key to save your changes or the ESC key to discard them. If the tag that you removed is the last instance of the tag, the tag is deleted from your organization completely. If other records use the tag, the tag still appears in search results and the Tags page. Tags Settings Tag settings available in:
All Editions
To modify tag settings: Administrators set up and manage personal and public tags by:
Enabling tags for accounts, activities, assets, campaigns, cases, contacts, contracts, dashboards, documents, events, leads, notes, opportunities, reports, solutions, tasks, and any custom objects (except relationship group members) Adding tags to the sidebar for their users Deleting personal tags for deactivated users
Tags Limits Available in:
All Editions
You can have a maximum of:
500 unique personal tags 5,000 instances of personal tags applied to records
Across all users, your organization can have a maximum of:
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
Custom Objects: Custom objects records store information that is unique and important to you and your organization. For example, your organization may use a custom object called Quotes to store data for your company's sales quotes. You can also use custom objects for custom applications, such as tracking software enhancements in a development life-cycle. Your administrator first defines the custom object and its properties, such as custom fields, relationships to other types of data, page layouts, and a custom user interface tab. Once the custom object is created and deployed to users, you can enter data to create individual custom object records. If your administrator has created a tab for the custom object, the tab displays a home page that lets you quickly create and locate custom object records. You can also sort and filter your custom object records using standard and custom list views. In addition, the tab lets you view and edit detailed information on each custom object record to which you have access. Administrators, and users with the Modify All Data permission, can import custom objects
Notes: Object Permissions
In Enterprise, Unlimited, and Developer Editions, when you create a custom object, the Read, Create, Edit, Delete, View All, and Modify All permissions for that object are disabled for any profiles in which View All Data or Modify All Data is disabled. You can change these permissions in custom profiles, but not standard profiles. That is, users with standard profiles (except System Administrator) can't access new custom objects you must assign them custom profiles and edit the profiles. To enable access to custom objects, do one of the following:
a.
For users with standard profiles: Clone the profiles of the users whose object permissions you want to change. b.
Edit the custom profiles, enabling the permissions you want.Tip

If enhanced profile list views are enabled for your organization, you can
change permissions for
multiple profiles from the list view.

c. Edit the users' accounts, assigning the appropriate cloned custom profiles.
For users with custom profiles, simply edit their profiles, enabling the permissions you want. Note In Contact Manager, Group, and Professional Editions, when you create a custom object, the Read, Create, Edit, and Delete permissions for that object are enabled for all profiles. Sharing Model The data sharing model for all custom objects is controlled by an organization-wide default setting. For more information, see Custom Object Security. Delegating Custom Object Administration After you create a custom object, you can delegate the administration of the custom object to other nonadministrator users. Queues After you create a custom object, you can define users. Search Custom object records appear in search results only if they have a custom tab.
queues to distribute ownership of custom object records to your
Deploying Custom Objects Available in:
Contact Manager, Group, Professional, Enterprise, Unlimited, and Developer Editions
To deploy custom objects:
While developing custom objects, you may not want users to see and interact with a new object. Because users may get frustrated with changes in layout or lose data when you delete custom fields, control visibility of the new object until you are finished. Use the Deployment Status setting in the custom object definition to control when users can see and use a custom object and its associated custom tab, related lists, and reports.
Choose In Development as the Deployment Status when first creating your custom object to hide it from users while you are designing and testing it. Making the status In Development hides the custom object tab, search results, related lists, and report data types from all users except those with the Customize Application permission. Change the Deployment Status to Deployed when you want to allow all users to use the custom object and any associated custom tab, related lists, and reports. After deploying a custom object, change the Deployment Status back to In Development if you want to make more enhancements to it.
Note A custom report type's Deployment Status will automatically change from Deployed to In Development if its primary object is a custom object whose Deployment Status changes from Deployed to In Development. For more information, see Defining Custom Report Types. Deleting Custom Objects Available in:
To delete custom objects:
To delete custom objects: 1. 2. 3. Click Your Name | Setup | Create | Objects. Next to the custom object, click
Del. Delete.
When prompted, select the Yes, I want to delete the custom object checkbox to confirm, and click
Notes on Deleting Custom Objects
When you delete a custom object, Salesforce does not list it in the Recycle Bin with other deleted records. Instead, deleted objects appear in the Deleted Custom Objects list for 45 days. During this time you can restore an object and the data stored in it, or permanently erase the object and its data. After 45 days, the object and its data are permanently erased. If a user clicks a bookmark to a deleted custom object record's URL, Salesforce displays an Insufficient Privileges message. For more information on restoring custom objects, see Managing Deleted
Custom Objects.
Until permanently erased, the custom object and its data still count against the maximum number of items allowed in your organization. To view a list of the maximum number of custom objects, fields, and other items allowed in your organization, see Salesforce Editions and Limits. When you delete a custom object, Salesforce does the following:
o o o
Removes the object from Force.com AppExchange packages. If the deleted object is on the detail side of a master-detail relationship, changes the master-detail relationship to a lookup relationship. Permanently erases:
The object's data records currently in the Recycle Bin Custom tab, which is removed from any custom apps List views for the object Workflow rules and actions that use the object Mobile configuration settings, including data sets, mobile views, and excluded fields If the deleted object is on the detail side of a master-detail relationship:
Standard report types associated with this object Reports based on standard report types
Hides, inactivates, or disables: The custom object definition and all related definitions
The object's data records and all related data records Custom report types for which this is the main object Custom reports for which this is the main object Custom formula fields on the object Custom validation rules and approval processes on the object
Salesforce restores these items if you restore the custom object.
You cannot delete a custom object if it is on the master side of a master-detail relationship. When you delete a custom object that is on the detail side of a master-detail relationship, the relationship is converted to a lookup relationship. If you restore the custom object, you must manually convert it to a master-detail. See Changing
Custom Field Type .

You cannot delete a custom object if it is a target object in an analytic snapshot. You cannot delete a custom object that contains custom fields that are used in a roll-up summary field for another object. Page layouts on a custom object are deleted and restored with it. However, custom object data can also exist on page layouts for other objects in the form of related lists. These related lists remain until you edit the page layout, at which time Salesforce permanently removes any items relating to the deleted custom object.
You cannot delete a custom object if it is referenced in: o An Apex script
o o
A Visualforce page An analytic snapshot
In a many-to-many relationship, a user cannot delete a parent record if there are more than 200 junction object records associated with it and if the junction object has a roll-up summary field that rolls up to the other parent. To delete this object, manually delete junction object records until the count is fewer than 200
Managing Deleted Custom Objects Available in: Contact Manager, Group, Professional, Enterprise, Unlimited, and Developer Editions User Permissions Needed To restore deleted custom objects: To permanently delete custom objects: Customize Application Customize Application
When you delete a custom object, Salesforce does not list it in the Recycle Bin with other deleted records. Instead, deleted objects appear in the Deleted Custom Objects list for 45 days. During this time you can restore an object and the data stored in it, or permanently erase the object and its data. After 45 days, the object and its data are permanently erased. If a user clicks a bookmark to a deleted custom object record's URL, Salesforce displays an Insufficient Privileges message. Until permanently erased, the custom object and its data still count against the maximum number of items allowed in your organization. To view a list of your deleted custom objects: 1. 2. Click Your Name | Setup | Create | Objects. Click Deleted Objects at the bottom of the list of custom objects. The number in parentheses indicates the total number of deleted custom objects in your organization. This link only displays when you have a deleted custom object. 3. Use the list of deleted custom objects to perform the following actions:
To view details about an object, click the label. To permanently remove the custom object and its data, click Erase. To restore the object and its data, click Undelete. Some attributes of deleted custom objects are not
automatically restored. To restore these manually, complete the following steps:
o o o o o o o o o
The developer name was changed to
objectname_del. Edit the object to change the developer name.
The custom object's Deployment Status field was set to In Development. When all changes impacted by the delete have been restored, edit the object to change the status to Deployed. Add the custom object to any appropriate Force.com AppExchange packages. Salesforce automatically removes deleted custom objects from packages that contain them. Recreate any custom tabs and list views for the custom object and add the custom tab to any custom apps as required. Rebuild any workflow rules on the object. Reactivate any custom validation rules for the object. Reactivate any approval processes for the object. Open and save any custom formula fields on the custom object to enable them. On the page layouts of other objects, add the custom object related list, button, or link to any page layouts that have been edited while the object is deleted. Related lists, buttons, or links to this object are automatically restored if the page layout is not edited while the object is deleted.
For custom report types where the object is not the main object, add the reference to the custom object back to the custom report types. Reports based on the custom report type are automatically restored if not edited while the object is deleted. Recreate any reports that have been edited.
If the deleted custom object is on the detail side of a master-detail relationship:

Note
Master-detail fields are converted to lookup fields when the object is deleted. Change the field types back to master-detail. Reports based on the object are not restorable. Where appropriate, recreate the reports.
It may take several hours before you can search for records in the object.
About Default Field Values Available in:
Use default field values to make your users more productive by reducing the number of fields they need to fill in manually. Default field values automatically insert the value of a custom field when a new record is created. A default value can be based on a formula for some types of fields or exact values such as Checked or Unchecked for checkbox fields. After you have defined default values: 1. 2. 3. 4. 5. The user chooses to create a new record. Default field value is executed. Salesforce displays the edit page with the default field value pre-populated. The user enters the fields for the new record. The user saves the new record.
The user can change the field's value but the initial default field value is only executed once, during record creation. For example, you can set the default field value on a custom lead field to seven days after the creation date to signify when to contact the lead again. You can change this value later, but you cannot automatically restore the value that was seven days after the creation date. Set up default field values for the following types of custom fields:
Checkbox Currency Date
Date/Time Email Number Percent Phone Picklist (use the default option when setting up the picklist) Text Text Area URL
Useful Default Field Formulas: https://ap1.salesforce.com/help/doc/en/fields_useful_default_field_values.htm About Encrypted Custom Fields Available in:
Developer, Enterprise, and Unlimited Editions
Encrypted custom fields are text fields that can contain letters, numbers, or symbols but are encrypted. The value of an encrypted field is only visible to users that have the View Encrypted Data permission. Before you begin working with encrypted custom fields, review the following implementation notes and best practices: Implementation Notes
To enable encrypted fields for your organization, contact salesforce.com. Encrypted fields are encrypted with 128-bit master keys and use the AES (Advanced Encryption Standard) algorithm. You can archive, delete, and import your master encryption key. To enable master encryption key management, contact salesforce.com. See also Managing Salesforce Master Encryption Keys.
Encrypted custom fields cannot be unique, an external ID, or have default values. While 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 Mobile, Connect Offline, Connect for Lotus Notes, Connect for Outlook, Salesforce for Outlook, 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 yet 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, 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. Only the <apex:outputField> component supports presenting encrypted fields in Visualforce pages.
Best Practices
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. Both work 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. Picklist Limitations Available in:
All Editions
To change picklists:
The maximum number of entries you can have in a standard or custom picklist is determined by the total number of characters allowed in the picklist, which is 15,000 characters. Note that each entry includes a linebreak and a return character that are not visible. These two additional characters per entry are counted as part of the 15,000 character limit. Additional limits apply to both standard and custom picklists. Additional Limits for Standard Picklists For standard picklists, entries can be up to 40 characters, not including linebreaks and returns. For standard multi-select picklists, the total number of characters for all entries cannot exceed 255. For standard picklists in organizations that use record types or the Translation Workbench, you can have an unlimited number of entries with the following exceptions for special picklists: Picklist Field Maximum Number of Entries
Lead Status
100
Task Status
100
Task Priority
50
Case Status
100
Case Priority
50
Opportunity Stage
100
Additional Limits for Custom Picklists Within the 15,000 total character limit, custom picklists can have:
Up to 1,000 entries Up to 255 characters per entry
Custom multi-select picklists can have:
Up to 150 values Up to 40 characters per value
Note that for multi-select picklists, users can select up to 100 values at a time on a record. Using the HYPERLINK function in a text formula enables you to build dynamic links in custom fields. You can now put a link anywhere you can put a custom field - on Activities, related lists, list views, reports or search results. Possible uses included: - Run a report - Dial a phone number - Initiate a chat or web conference session - Integrate external content - Initiate a related Salesforce CRM transaction (edit or create a related record) Some design differences to consider between hyperlink formulas and Custom Links: Custom links will display on detail pages in a predefined section hyperlink formula fields can be placed anywhere a custom field can. Custom links have specified properties like new window size, etc. hyperlink formula fields always open in a new window. Custom links can reference parent, org and API fields. Hyperlink formula fields can only reference fields in the same object. Custom links can execute URLs or s-Controls. Hyperlink formula fields can only reference URLs or files. They can execute the URL of the custom link servlet, making it possible to execute an s-Control. Custom Links are not controlled by field level security. Hyperlink formula fields are controlled by field level security. Hyperlink formula fields that contain relative URLs to Salesforce CRM pages, such as /rpt/reportwizard.jsp, can be added to list views, reports and related lists. However, use a complete URL, including the server name and https://, in your hyperlink formula before adding it to a search layout. Hyperlink formula fields can execute links (URLs or s-Controls) with this format: HYPERLINK("servlet/servlet.Integration?id=00bx00000001pIK&eid=001x0000002g6ou","click here") Custom formula fields enable customers to define their own business specific calculations and metrics inside Salesforce. With custom formula fields Administrators can define numeric, text, and date calculations which are tailored to specific business needs. Below are some of the guidelines that govern the use of custom formula fields. Formula Fields are included in Professional, Enterprise, Unlimited, and Developer Editions. - User profiles with the 'Customize Application' permission can setup and customize formula fields - Formula fields are read-only fields, and therefore not displayed on record edit pages - Formula fields can reference fields within the same object, a parent object, or a lookup object, but not fields on child objects - Formula fields can reference standard, custom, or other formula fields. - Cyclic formula references are not allowed. - Fields used in formulas cannot be deleted (System Admin must remove them from the formula first before deleting). - Description, long text area custom fields, & multi select picklists cannot be used. - Currency codes cannot be used. - Aggregation functions (Sum, Count, Min, Max) of data from child records are not supported by this feature. Use Roll-Up Summary Fields to perform this type of calculation.
- Formula fields are not available in Offline Edition or Outlook Edition, they are not searchable via sidebar or advanced search, are not available for lead conversion, and are not included in data exports. CHARACTER LIMITATIONS 3,900 character limit per custom formula field. 5,000 character limit in the SQL query generated per formula field. 32,000 character limit on the SQL statement for entire object, including all standard and custom fields and all formula fields.
Overview of Relationships
Available in: Contact Manager, Group, Professional, Enterprise, Unlimited, and Developer Editions
Use relationships to associate an object with other objects in Salesforce. For example, a relationship can link custom object records to standard object records in a related list, such as linking a custom object called Bugs to cases to track product defects associated with customer cases. You can define different types of relationships by creating custom relationship fields on an object. Before you begin creating relationships, determine the type of relationship that suits your needs. There are different types of relationships between objects in Salesforce. Their differences include how they handle data deletion, record ownership, security, and required fields in page layouts: Master-detail This type of relationship closely links objects together such that the master record controls certain behaviors of the detail and subdetail record. For example, you can define a two-object master-detail relationship, such as AccountExpense Report, the extend the relationship to subdetail records, such as AccountExpense ReportExpense Line Item. You can then perform operations across the masterdetailsubdetail relationship. Behaviors of master-detail relationships include:
When a master record is deleted, the related detail and subdetail records are also deleted. The Owner field on the detail and subdetail records is not available and is automatically set to the owner of the master
record. Custom objects on the detail side of a master-detail relationship cannot have sharing rules, manual sharing, or queues, as these require the Owner field.
The security settings for the master record control the detail and subdetail records. The master-detail relationship field (which is the field linking the objects) is required on the page layout of the detail and
subdetail records.
The master object can be a standard object, such as Account or Opportunity, or a custom object.
Tip If you have a custom object called Expenses and you want each expense record deleted along with its associated opportunity record, create a master-detail relationship on the Expenses custom object with Opportunity as the master object. Many-to-many You can use master-detail relationships to model many-to-many relationships between two standard objects, two custom objects, or a custom object and a standard object. A many-to-many relationship allows each record of one object to be linked to multiple records from another object and vice versa. For example, you may have a custom object called Bug that relates to the standard case object such that a bug could be related to multiple cases and a case could also be related to multiple bugs. See Creating a Many-to-Many Relationship. Lookup This type of relationship links two objects together, but it has no effect on deletion, record ownership, or security, and the lookup relationship field is not required in the page layout. Use lookup relationships to:
Link two different objects, custom or standard. Link an object with itself, custom or standard (with the exception of the user object; see Hierarchical). For example, you
may want to link a custom object called Bug with itself to show how two different bugs are related to the same problem. Note Lookup relationships from objects related to the campaign member object are not supported, however, you can create lookup relationships from the campaign member object related to other objects. When you define a lookup relationship, you have the option to include a lookup field on the page layouts for that object as well as create a related list on the associated object's page layouts. For example, if you have a custom object called PTO Requests and you want your users to link a PTO request with the employee submitting the request, create a lookup relationship from the PTO Request custom object with the user object. Hierarchical This type of relationship is a special lookup relationship available only for the user object. It allows users to use a lookup field to associate one user with another that does not directly or indirectly refer to itself. For example, you can create a custom hierarchical relationship field to store each user's direct manager.Tip When creating a hierarchical field in Personal, Contact Manager, Group, and Professional Editions, you can select the Restricted Field checkbox so that only users with the Manage Users permission can edit it. In Enterprise, Unlimited, and Developer Edition, use field-level security instead.
Considerations for Relationships

Review the following considerations before creating relationships between objects: Relationship Limits Each custom object can have up to two master-detail relationships and many lookup relationships. Each relationship is included in the maximum number of custom fields allowed. For the total number of custom fields you can create, see Salesforce Editions and Limits. Changing and Converting Relationships After you have created a relationship, you cannot change which objects are related via that relationship. If you need to do this, delete the relationship and create a new relationship. You can convert a master-detail relationship to a lookup relationship as long as no roll-up summary fields exist on the master object. You can convert a lookup relationship to a master-detail relationship, but only if the lookup field in all records contains a value. Self Relationships You can create a relationship from an object to itself, but it must be a lookup relationship, and a single record cannot be linked to itself. However, a record can indirectly relate to itself. For example, the Holiday Promotion campaign can have the Direct Mail campaign selected in the lookup relationship, and the Direct Mail campaign can have the Holiday Promotion campaign selected in the lookup relationship. You cannot create a many-to-many self relationship, that is, the two master-detail relationships on the junction object cannot have the same master object. Icons for Custom Related Lists The icon you select for the associated custom tab also displays in any custom related list you create based on a relationship. For more information on choosing the icon for your custom tab, see Creating Custom Object Tabs. Custom related lists do not include an icon if they are based on a relationship with a custom object that does not have a custom tab.
Master-Detail Relationships To create multilevel master-detail relationships, you need the "Customize Application" user permission. When you define a master-detail relationship, the custom object on which you are working is the detail side. Its data can appear as a custom related list on page layouts for the other object. If a custom object is detail or subdetail component a master-detail relationship, it cannot also be the master of a different master-detail relationship. You can have up to three custom detail levels. Standard objects cannot be on the detail side of a custom object in a master-detail relationship. An object can appear once in multilevel master-detail relationships. For example, a subdetail object in one multilevel master-detail relationship cannot also be the owner of the master object in another multilevel master-detail relationship. A subdetail object cannot also be the master object of the subdetail object's detail object. Multilevel master-detail relationships do not support division transfers. You cannot create a master-detail relationship if the custom object already contains data. You can, however, create the relationship as a lookup and then convert it to master-detail if the lookup field in all records contains a value. Converting relationships from lookup to master-detail, or from master-detail to lookup behaves the same as for two-object master-detail relationships. That is, the two linked objects in the detail-subdetail1, or subdetail1-subdetail2 relationship have the same conversion limits as the master-detail relationship. Roll-up summary fields work as in two-object master-detail relationships. A master can roll up fields on detail records; however, it cannot directly roll up fields on subdetail records. To achieve this, the detail record must have a roll-up summary field for the field on the subdetail record, allowing the master to roll up from the detail's roll-up summary field. You can use multilevel master-detail relationships in custom report types. The Allow Reports checkbox must be checked when you create the custom object. Custom report types created for multilevel master-detail relationships count towards the organizations custom report type limit and no reports are generated if this limit is exceeded. See Salesforce Editions and Limits. Custom junction objects, cannot have detail objects. That is, a custom junction object cannot become the master object in a multilevel master-detail relationship. When you delete a custom object that is on the detail side of a master-detail relationship, the relationship is converted to a lookup relationship. If you restore the custom object, you must manually convert it to a master-detail. See Changing Custom Field Type . You cannot delete a custom object if it is on the master side of a master-detail relationship. Undeleting the master record also undeletes detail and subdetail records. Many-to-Many Relationships Junction object records are deleted when either associated master record is deleted and placed in the Recycle Bin. If both associated master records are deleted, the junction object record is deleted permanently and cannot be restored. Sharing access to a junction object record is determined by a user's sharing access to both associated master records and the Sharing Setting option on the relationship field. See Custom Object Security. For example, if the sharing setting on both parents is Read/Write, then the user must have Read/Write access to both parents in order to have Read/Write access to the junction object. If, on the other hand, the sharing setting on both masters is Read-Only, a user with Read-Only rights on the master records would have Read/Write access to the junction object. You can create workflow rules and approval processes on junction objects; however, you cannot create outbound messages on junction objects. In a many-to-many relationship, a user cannot delete a parent record if there are more than 200 junction object records associated with it and if the junction object has a roll-up summary field that rolls up to the other parent. To delete this object, manually delete junction object records until the count is fewer than 200. The first master-detail relationship you create on your junction object becomes the primary relationship. This affects the following for the junction object records:
Look and feel: The junction object's detail and edit pages use the color and any associated icon of the primary master
object.
Record ownership: The junction object records inherit the value of the Owner field from their associated primary master record. Because objects on the detail side of a relationship do not have a visible Owner field, this is only relevant if you
later delete both master-detail relationships on your junction object.
Division: If your organization uses divisions to segment data, the junction object records inherit their division from their
associated primary master record. Similar to the record ownership, this is only relevant if you later delete both masterdetail relationships. The second master-detail relationship you create on your junction object becomes the secondary relationship. If you delete the primary master-detail relationship or convert it to a lookup relationship, the secondary master object becomes primary. Roll-up summary fields that summarize data from the junction object can be created on both master objects. Formula fields and validation rules on the junction object can reference fields on both master objects. You can define Apex triggers on both master objects and the junction object. A junction object cannot be on the master side of another master-detail relationship. You cannot create a many-to-many self relationship, that is, the two master-detail relationships on the junction object cannot have the same master object. Impact of Relationships on Reports The type of relationship you create affects which standard report types are available and how they are categorized. These report types determine which related objects can be included in the report:
Lookup relationships allow data from the two related objects to be joined in one report. Master-detail relationships allow data from three objects to be joined in one report: the master object, the detail object,
plus one other lookup object. If the detail object has multiple lookup relationships, a separate report type is available based on each lookup.
Many-to-many relationships provide two standard report types that join the master objects and the junction object. The
report types are:
o o
Primary master with junction object and secondary master in the primary master object's report category Secondary master with junction object and primary master in the secondary master object's report category The order of the master objects in the report type is important. The master object listed first determines the scope of records that can be displayed in the report.
The reporting impact of each relationship type is summarized in the following table:
Relationship Type Standard Report Types
Report Type Category

Based on the object
Lookup
Object by itself Object with first lookup Object with second lookup Object with third lookup
Master-Detail
Master object by itself Master object with detail object Master object with detail object and first lookup Master object with detail object and second lookup Master object with detail object and third lookup
Master object
Many-to-Many
Primary master object by itself Secondary master object by itself
Primary master object and
Relationship Type Standard Report Types
Report Type Category
Primary master object with junction object and secondary master object Secondary master object Secondary master object with junction object and primary master object Custom report types give you more flexibility to join data from multiple objects, including lookups as well as master-detail relationships. Important Converting a relationship from lookup to master-detail or vice versa can cause existing custom reports to become unusable due to the different standard report types available for each type of relationship. We recommend that you test your custom reports immediately after converting the relationship type. If you revert your relationship back to the original type, the reports are restored and become usable again.
Creating a Many-to-Many Relationship


To create a many-to-many relationship:
You can use master-detail relationships to model many-to-many relationships between two standard objects, two custom objects, or a custom object and a standard object. A many-to-many relationship allows each record of one object to be linked to multiple records from another object and vice versa. For example, you may have a custom object called Bug that relates to the standard case object such that a bug could be related to multiple cases and a case could also be related to multiple bugs. When modeling a many-to-many relationship, you use a junction object to connect the two objects you want to relate to each other. Junction Object A custom object with two master-detail relationships. Using a custom junction object, you can model a many-to-many relationship between two objects. For example, you may have a custom object called Bug that relates to the standard case object such that a bug could be related to multiple cases and a case could also be related to multiple bugs. Creating the many-to-many relationship consists of: 1. 2. 3. 4. Creating the junction object. Creating the two master-detail relationships. Customizing the related lists on the page layouts of the two master objects. Customizing reports to maximize the effectiveness of the many-to-many relationship.
Creating the Junction Object

To create the junction object: 1. 2. 3. Click Your Name | Setup | Create | Objects. Click New Custom Object. In the custom object wizard, consider these tips specifically for junction objects:
Name the object with a label that indicates its purpose, such as BugCaseAssociation. For the Record Name field, it is recommended that you use the auto-number data type. Do not launch the custom tab wizard before clicking Save. Junction objects do not need a tab.
Creating the Two Master-Detail Relationships

To create the two master-detail relationships: 1. Verify that the two objects you want to relate to each other already exist. For example, you may want to relate the standard case object to a custom bug object.
2.
On the junction object, create the first master-detail relationship field. In the custom field wizard: a. b. Choose Master-Detail Relationship as the field type. Select one of the objects to relate to your junction object. For example, select Case. The first master-detail relationship you create on your junction object becomes the primary relationship. This affects the following for the junction object records:
Look and feel: The junction object's detail and edit pages use the color and any associated icon of the primary master object. Record ownership: The junction object records inherit the value of the Owner field from their associated primary master record. Because objects on the detail side of a relationship do not have a visible Owner field, this is only relevant if you later delete both master-detail relationships on your junction object.
Division: If your organization uses divisions to segment data, the junction object records inherit their division from their associated primary master record. Similar to the record ownership, this is only relevant if you later delete both master-detail relationships.
c.
Select a Sharing Setting option. For master-detail relationship fields, the Sharing Setting attribute determines the sharing access that users must have to a master record in order to create, edit, or delete its associated detail records.
d.
For the Related List Label that will display on the page layout of the master object, do not accept the default. Change this to use the name of the other master object in your many-to-many relationship. For example, change this to Bugs so users will see a Bugs related list on the case detail page.
3.
On the junction object, create the second master-detail relationship. In the custom field wizard: a. b. Choose Master-Detail Relationship as the field type. Select the other desired master object to relate to your junction object. For example, select Bug. The second master-detail relationship you create on your junction object becomes the secondary relationship. If you delete the primary master-detail relationship or convert it to a lookup relationship, the secondary master object becomes primary. c. Select a Sharing Setting option. For master-detail relationship fields, the Sharing Setting attribute determines the sharing access that users must have to a master record in order to create, edit, or delete its associated detail records. d. For the Related List Label that will display on the page layout of the master object, do not accept the default. Change this to use the name of the other master object in your many-to-many relationship. For example, change this to Cases so users will see a Cases related list on the bug detail page.
Customizing Many-to-Many Relationship Related Lists

For a many-to-many relationship in Salesforce, each master object record displays a related list of the associated junction object records. To create a seamless user experience, you can change the name of the junction object related list on each of the master object page layouts to have the name of the other master object. For example, you might change the BugCaseAssociations related list to Cases on the bugs page layout and to Bugs on the cases page layout. You can further customize these related lists to display fields from the other master object. To customize the fields that display in the junction object related list on each master object page layout: 1. Edit the page layout of each master object that is related to the junction object. For example, to modify the BugCaseAssociations related list for case records, edit the page layout for cases at Your Name |Setup | Customize | Cases | Page Layouts. 2. 3. Edit the properties of the related list you want to modify. For example, on cases the BugCaseAssociations related list was renamed to Bugs, so select the Bugs related list. Add the fields to display in the related list. You can add fields from the junction object itself, but more importantly, you can add fields from the other master object. Each field is prefixed with its object name in the popup window. In the related list itself, only fields from the junction object are prefixed with the object name; fields from the other master object are not.
Note The junction object related list does not include an icon on the master record's detail pages because the junction object does not have a custom tab. If you make a tab for the junction object, the icon is included. Customizing Reports for Many-to-Many Relationships
Many-to-many relationships provide two standard report types that join the master objects and the junction object. The report types are:
Primary master with junction object and secondary master in the primary master object's report category Secondary master with junction object and primary master in the secondary master object's report category
The order of the master objects in the report type is important. The master object listed first determines the scope of records that can be displayed in the report. You can create custom reports based on these standard report types. In addition, you can create custom report types to customize which related objects are joined in the report. If a custom object is detail or sub detail component a master-detail relationship, it cannot also be the master of a different master-detail relationship. You can have up to three custom detail levels. Standard objects cannot be on the detail side of a custom object in a master-detail relationship. An object can appear once in multilevel master-detail relationships. For example, a sub detail object in one multilevel master-detail relationship cannot also be the owner of the master object in another multilevel master-detail relationship. A sub detail object cannot also be the master object of the sub detail object's detail object. You cannot create a master-detail relationship if the custom object already contains data. You can, however, create the relationship as a lookup and then convert it to master-detail if the lookup field in all records contains a value. Converting relationships from lookup to master-detail, or from master-detail to lookup behaves the same as for two-object master-detail relationships. That is, the two linked objects in the detail-subdetail1, or subdetail1-subdetail2 relationship have the same conversion limits as the master-detail relationship. Roll-up summary fields work as in two-object master-detail relationships. A master can roll up fields on detail records; however, it cannot directly roll up fields on sub detail records. To achieve this, the detail record must have a roll-up summary field for the field on the sub detail record, allowing the master to roll up from the detail's roll-up summary field. You can use multilevel master-detail relationships in custom report types. The Allow Reports checkbox must be checked when you create the custom object. Each custom object can have up to two master-detail relationships and many lookup relationships. When a master record is deleted, the related detail and subdetail records are also deleted. The Owner field on the detail and subdetail records is not available and is automatically set to the owner of the master record. Custom objects on the detail side of a master-detail relationship cannot have sharing rules, manual sharing, or queues, as these require the Owner field. The security settings for the master record control the detail and subdetail records. The master-detail relationship field (which is the field linking the objects) is required on the page layout of the detail and subdetail records. The master object can be a standard object, such as Account or Opportunity, or a custom object.
https://na1.salesforce.com/_ui/training/help/pub/UserEdSolution?id=50130000000MBmk&retURL=https%3A%2F% 2Fap1.salesforce.com%2F_ui%2Ftraining%2Fhelp%2FCombinedSearchPage%3Fstr%3DRelationships&ps=1&orgId=00 D000000000062
Overview of Page Layouts and Field-Level Security

Page layouts and search layouts available in: All Editions Field-level security available in: Enterprise, Unlimited, and Developer Editions
Use field-level security to control the access that users have to certain fields. Additionally, use page layouts to control the layout and organization of detail and edit pages in Salesforce, the Self-Service Portal, and the Salesforce Customer Portal. Customize search layouts to change which fields display in search results and the buttons that display on list views.
Important While you can use page layouts to hide fields from detail and edit pages, be aware that users may still be able to access those fields by other means, including reports, search results, list views, and the API. Use field-level security to restrict all means of accessing a field. Field-level security doesn't prevent searching on
the values in a field. To set up your organization to prevent users from searching and retrieving records that match a value in a field hidden by field-level security, contact salesforce.com Customer Support. Field-Level Security
Restrict users access to view and edit fields by any means, including reports, search results, list views, related lists, email and mail merge templates, custom links, Connect Offline, the API, and when synchronizing data or importing personal data. Override any less-restrictive field access settings in page layouts and mini page layouts. For example, if a field is required in the page layout and read only in the field-level security settings, the field-level security overrides the page layout and the field will be read only for the user.
Override less-restrictive field settings in search layouts. For example, if a field is visible in the search layout but hidden for certain users via the field-level security settings, the fieldlevel security overrides the search layout and the field will be hidden for those users.
Page Layouts
Control the layout and organization of detail and edit pages Control which fields, related lists, and custom links users see, on detail and edit pages only Control which standard and custom buttons display on detail pages and related lists Determine whether fields are visible, read only, or required, on detail and edit pages only In Personal, Contact Manager, Group, and Professional Editions, control which fields users can access in related lists, list views, reports, Connect Offline, email and mail merge templates, custom links, and when synchronizing data or importing personal data
In Professional, Enterprise, Unlimited, and Developer Editions, determine some aspects of mini page layouts, including record type and profile associations, related lists, fields, and field access settings. The visible fields and related lists of the mini page layout can be further customized, but the other items inherited from the associated page layout cannot be changed on the mini page layout itself. Mini page layouts display selected fields and related lists of records in the mini view of the console. See Console Tab Overview for more information.
Note To automatically add a field to all page layouts and make it visible and required everywhere regardless of fieldlevel security, make it a universally required field.
Managing Page Layouts

Available in: All Editions

To create, edit, and delete page layouts: Customize Application
You can customize the page layouts for record detail and edit pages, Self-Service portal pages, Salesforce Customer Portal pages, and the case close page. Page layouts control the layout and organization of buttons, fields, s-controls, Visualforce, custom links, and related lists. They also help determine which fields are visible, read only, and required. Page layouts can include s-controls and Visualforce pages that are rendered within a field section when the page displays. You can control the size of the s-controls and Visualforce pages, and determine whether or not a label and scroll bars display. To work with page layouts, go to Your Name | Setup | Customize, click the appropriate kind of record, and select Page Layouts. You can:
Click New to create layouts; see Creating Page Layouts. Click Edit to modify layouts or customize related lists; see Customizing Page Layouts.
Click Del to delete layouts; see Deleting Page Layouts. Click Page Layout Assignment to assign page layouts to profiles and record types; see Assigning Page Layouts.
For Personal, Contact Manager, Group, and Professional Edition organizations, every user views the same layout. Enterprise, Unlimited, and Developer Edition organizations can create different page layouts for use by different profiles and record types and set field-level security settings to further restrict users access to specific fields. See Assigning Page Layouts and Setting FieldLevel Security for more information. In Professional, Enterprise, Unlimited, and Developer Editions, you can set the mini page layouts and related objects that appear in the Console tab. See Choosing Related Objects for the Console's Mini View and Defining Mini Page Layouts for more information.
Tip 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. Note that field-level security settings override the visible and read-only settings on the page layout if the field-level security has a more restrictive setting than the page layout. Note Salesforce periodically runs a background process that cleans up metadata associated with deleted custom fields. This process will affect the Last
Modified Date and Last Modified By fields on
page layouts, record types, and custom objects.
Setting Field-Level Security

Available in: Enterprise, Unlimited, and Developer Editions

Customize Application You can define which fields users can access. Field-level security settings let administrators restrict users access to view and edit specific fields in the following places: To set field-level security:
Detail and edit pages Related lists List views Reports Connect Offline Email and mail merge templates Custom links The partner portal The Salesforce Customer Portal Synchronized data Imported personal data
The fields that users see on detail and edit pages are a combination of page layouts and field-level security settings. The most restrictive field access settings of the two always apply. For example, if a field is required in the page layout and read only in the field-level security settings, the field-level security overrides the page layout and the field will be read only for the user.
Important Field-level security doesn't prevent searching on the values in a field. To set up your organization to prevent users from searching and retrieving records that match a value in a field hidden by field-level security, contact salesforce.com Customer Support.
You can define field-level security for multiple fields on a single profile or for a single field on all profiles.
Setting Access for Fields on a Single Profle
1. 2. 3. 4.
Select Your Name | Setup | Manage Users | Profiles. Select a profile. In the Field-Level Security section, click View next to the tab you want to modify, and then click Edit. Specify the field's access level.
Access Level
Enabled Settings
Users can view and edit the field.
Visible
Users can view but not edit the field.Visible and Read-Only
Users can't view or edit the field.
None
5.
Note 6. When changing field settings for accounts, opportunities, cases, contacts, or custom objects, check for any criteria-based sharing rules that use the field in the rules. For example, if you hide a field that's used in a criteriabased sharing rule, any users who could access certain records because of the sharing rule will no longer have access to those records.
7.
Click Save.
After setting field-level security for users based on their profiles, you can:
Create page layouts to organize the fields on detail and edit pages. Tip 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.
Note
Verify users access to fields by checking the field accessibility grid.
Set the fields that display in search results, in lookup dialog search results, and in the key lists on tab home pages.
Roll-up summary and formula fields are always read only on detail pages and not available on edit pages. They may also be visible to users even though they reference fields that your users cannot see. Universally required fields always display on edit pages regardless of field-level security. The relationship group wizard allows you to create and edit relationship groups regardless of field-level security. For more information on the behaviors of relationship group members, see Relationship Group Considerations. Setting Access for a Single Field on All Profiles
1. 2. 3. 4. Select Your Name | Setup | Customize, click a tab or activity link, and click Fields. Select the field you want to modify. Click Set Field-Level Security. Specify the field's access level.
Access Level
Enabled Settings
Users can view and edit the field.
Visible
Users can view but not edit the field.Visible and Read-Only
Access Level
Enabled Settings
Users can't view or edit the field.
None
5.
Note 6. When changing field settings for accounts, opportunities, cases, contacts, or custom objects, check for any criteria-based sharing rules that use the field in the rules. For example, if you hide a field that's used in a criteriabased sharing rule, any users who could access certain records because of the sharing rule will no longer have access to those records.
7.
Click Save.
Change Sets:

To edit deployment connections: To use outbound change sets: Deploy Change Sets Create and Upload Change Sets, Create AppExchange Packages, AND Upload AppExchange Packages To use inbound change sets: Deploy Change Sets
A change set is a means by which one organization can send customizations to another organization. For example, you could create a new object in a sandbox organization and send it to your production organization using a change set. Change sets can only contain modifications you can make through the Setup menu; therefore, you can't use a change set to upload a list of contact records. In other words, change sets contain metadata, not data. When you want to send customizations from your current organization to another organization, you create an outbound change set. Once you send the change set, the receiving organization sees it as aninbound change set. Sending a change set between two organizations requires a deployment connection. Currently, change sets can only be sent between organizations that are affiliated with a production organization, for example, a production organization and a sandbox, or two sandboxes created from the same organization.
Components Available in Change Sets

The following types of components may be added to a change set:
Analytic Snapshot Apex Class Apex Sharing Reason Apex Trigger App Button or Link Custom Field Custom Object Custom Report Type Custom Setting Dashboard Document Email Template Folder
Home Page Component Home Page Layout Letterhead List View Page Layout Record Type Remote Site Report S-Control Static resource Tab Validation Rule Visualforce Component Visualforce Page Workflow Email Alert Workflow Field Update Workflow Outbound Message Workflow Rule Workflow Task
Note If you create or modify components that are not available in a change set, you can't send those components from one organization to another in a change set. In this case, migrate the changes manually by repeating the steps you performed when you created or modified the component.
Viewing Inbound Change Sets

The Inbound Change Sets page lists change sets awaiting deployment, as well as the history of deployed change sets. To view inbound change sets, click Your Name | Setup | Deploy | Inbound Change Sets.
Note Inbound change sets are permanently deleted six months after the change set is uploaded.
An outbound change set is a change set created in the organization you are logged into and that you want to send to another organization. Typically, an outbound change set is used for customizations created and tested in a sandbox and then sent to a production organization. Sending an outbound change set to another organization doesn't guarantee that the changes will be implemented in that organization. The change set must deployed (accepted) by the target organization before the changes take effect.
Note Change sets are limited to 2,500 components and a total file size of 400 MB.
Cloning an Outbound Change Set

You can create a copy of an existing change set by cloning it. 1. 2. 3. Click Your Name | Setup | Deploy | Outbound Change Sets. Click the name of the change set you want to clone. Click Clone.
Selecting Components for an Outbound Change Set

To select the components in an outbound change set: 1. 2. 3. 4. 5. Click Your Name | Setup | Deploy | Outbound Change Sets. In the Change Sets list, click the name of a change set, or create a new one. Click Add to add components. Choose the type of component and the components you want to add, and then click Add to Change Set. Click Add Profiles to add profile settings to the change set. 6. Optionally, click View/Add Dependencies to add dependent components.Note
Dependent components rely on the existence of other components. Unless you are certain that the dependent components exist in every organization this change set will be deployed to, it's a good idea to add dependent components to the change set.
Uploading an Outbound Change Set

Once you've assembled the components in a change set, you can upload it to another organization. Note that once you upload a change set, you can't edit it or recall it. 1. 2. 3. 4. Click Your Name | Setup | Deploy | Outbound Change Sets. Click the name of a change set. Select the organization you want to send the change set to. Click Upload.
Note Outbound change sets expire six months after upload, at which time the change set is permanently deleted.
Viewing and Adding Dependent Components to a Change Set

A dependency is a relationship where one or more components must exist for another component to exist. It's a good idea to add dependent components to a change set, unless you are sure that the dependent components exist in every organization where this change set will be deployed. To add dependent components to an outbound change set: 1. 2. 3. 4. Click Your Name | Setup | Deploy | Outbound Change Sets. In the Change Sets list, click the name of a change set. Click View/Add Dependencies. On the Component Dependencies page, select the dependent components you wish to deploy and click Add to Change Set.
Outbound Change Set Validation Errors

If you receive an error about cross-version validation, then the organization used to create the outbound change set is running on a different platform version than the organization receiving the change set. This error typically occurs during upgrades, because organizations may be upgraded at different times. If you receive this error, you can only deploy those components that are compatible between versions.
Deleting an Outbound Change Set

To delete an outbound change set: 1. 2. 3. Click Your Name | Setup | Deploy | Outbound Change Sets. Click the name of the change set you want to delete. Click Delete.
Viewing Change Set Details

The Change Sets detail page lists information about a particular change set. 1. 2. Click Your Name | Setup | Deploy | Inbound Change Sets. Click the name of a change set.
Deploying a Change Set

To deploy a change set: 1. 2. 3. Click Your Name | Setup | Deploy | Inbound Change Sets. In the Change Sets Awaiting Deployment list, click the name of the change set you want to deploy. Click Deploy.
A change set is deployed in a single transaction. If the deployment is unable to complete for any reason, the entire transaction is rolled back. After a deployment completes successfully, all changes are committed to your organization and the change set cannot be rolled back.
Note The Force.com platform requires at least 75% of your code to be covered by unit tests before you can deploy it to a production organization. Ideally, you should strive for 100% coverage. The code coverage restriction is not enforced for sandbox or Developer Edition organizations.
Deployment Connections
To edit deployment connections:
Deploy Change Sets
In order for change sets to be sent from one organization to another, a deployment connection is required between the organizations. Deployment connections can't be created between arbitrary organizations; instead, a deployment connection is created between all organizations affiliated with a production organization. For example, if you have a production organization (Prod) and two sandboxes (Dev and Test), a deployment connection is created between production and each sandbox (Prod and Dev, and another connection between Prod and Test), as well as between the sandboxes (Dev and Test). A deployment connection alone doesn't enable change sets to be sent between organizations. Each organization must be authorized to send and receive change sets. This added level of security enforces code promotion paths and keeps organizations' setup metadata from being overwritten by mistake. For example, the following figure illustrates one possible migration path for a production organization and two sandboxes. In this example, the production organization can only receive changes that have been fully tested, so only the Test sandbox is authorized to upload change sets to production. In order to synchronize development projects with the production organization, the Prod organization can send change sets to the Dev sandbox, but not to the Test sandbox. Finally, because the features in development need iterative testing, Dev and Test sandboxes should be able to send change sets back and forth.
Change Set Authorization Enforces Code Path
Note This illustration describes one possible code migration path. Your department must create its own policies for organizations to send and receive change sets to one another.
Change Sets Best Practices

Deploy all dependent components Make sure each outbound change set contains all interdependent components that don't exist in the target organization. If you try to deploy a component that refers to another component missing from the target organization and from the change set, the deployment fails. Change sets give you fine-grained control over what you deploy. For example, you can migrate custom fields individually. To deploy a custom object and all of its fields, you must add the custom object and every field to the change set; adding just the custom object to the change set won't cause deployment to fail, but results in an empty custom object. Add profiles to outbound change sets Adding profiles to outbound change sets allows users with the appropriate permissions access to the new functionality. Clone a change set to add dependent components to an uploaded change set After you upload a change set, you can't change its contents. If you need to add dependent components to a change set you already uploaded, clone the change set, add the dependent components, and then upload it again. Plan deployments around maintenance schedule Plan your deployment activities around the maintenance schedule for both your production and sandbox organizations. Some features require information from your production organization when accessed from a sandbox. Validate change sets before deployment You can perform a test deployment of an inbound change set to view the success or failure messages that would occur with an actual deployment. This is a good idea if you are planning a deployment on a schedule (for example during lowuse hours) and want to determine if the deployment will succeed ahead of time. However, you don't need to perform a test deployment every time you deploy, as this process takes time to complete. To test deploy an inbound change set, click its name and then click Validate. View component details You can view the XML representation of a component before you upload an outbound change set or deploy an inbound change set. Change sets limited to 2500 components and 400 MB Change sets are limited to 2500 components and a total file size of 400 MB. If your change set exceeds either of these limits, you can create separate change sets for email templates, dashboards, and reports. These components are often the most numerous and have fewer dependencies. Deleting and renaming components
You can't use change sets to delete or rename components. To delete components, use the Web interface on the target organization. To rename a component, first delete the component on the target organization and then upload the new component in a change set.
Monitoring Metadata Deployments


To view metadata deployments:
Modify All Data
You can use the Metadata API to deploy XML file representations of components into an organization. A component is an instance of a metadata type in the Metadata API. For example, CustomObject is a metadata type for custom objects, and the MyCustomObject__c component is an instance of a custom object. The easiest way to access the Metadata API is to use the Force.com IDE or Force.com Migration Tool. These tools are built on top of the Metadata API and use the standard Eclipse and Ant tools respectively to simplify the task of working with the Metadata API. The deploy call in the Metadata API is asynchronous and may take a while to complete. The Force.com IDE and Force.com Migration Tool use the deploy call to move XML file representations of components into an organization. To track the status of deployments that are in progress or completed in the last 24 hours for these tools or other clients that are deploying metadata, click Your Name | Setup | Deploy |Monitor Deployments. The Deployments In Progress list contains the following columns:
Column
Description
Created By
The name of the user performing the deployment.
Start Time
The date and time when the deployment started.
Validate Only
Indicates whether this deployment is being used to check the validity of the deployed files without making any changes in the organization. A validate-only deployment does not deploy any components or change the organization in any way.
Status
The following values are possible:
QueuedThe deployment has not started. It is waiting in a queue. In ProgressThe deployment has started, but has not completed yet. Processing Type: typeThe deployment has started, and is processing a metadata type, where type is a metadata type, such as CustomObject. Processing nameThe deployment has started, and is processing a component, where name is a component name, such as MyCustomObject__c. Running Test ApexClass.testNameAn Apex test class is running, where ApexClass is the Apex class name and testName is the name of the test.
Components
The progress of the deployment. For example, 10 / 15 (3 errors) indicates that ten components have been processed successfully out of a total of 15. There were errors for three other components processed so far. The progress of the Apex tests that have been run. For example, 13 / 20 (2 errors) indicates that 13 tests have been run successfully out of a total of 20. There were errors for two other tests that have run so far. The value for the total number of tests is not accurate until the test phase of the deployment has started.
Tests
The Completed Deployments Last 24 Hours list contains the following columns. Completed deployments are removed from the list 24 hours after completion.
Column
Description
Created By
The name of the user who performed the deployment.
Start Time
The date and time when the deployment started.
End Time
The date and time when the deployment completed.
Validate Only
Indicates whether this deployment is being used to check the validity of the deployed files without making any changes in the organization. A validate-only deployment does not deploy any components or change the organization in any way.
Status
The following values are possible:
Components
CompletedThe deployment completed successfully. Completed with ErrorsThe deployment completed, but some components failed to deploy or some tests failed. This status cannot happen in a production organization as any errors cause the deployment to be rolled back. FailedThe deployment had some errors and no changes were made to the organization.
The number of components, including those with errors, that were processed in the deployment. For example, 10 (1 error) indicates that ten components were processed and there was an error for one component. The number of Apex tests, including those with errors, that were run. For example, 13 (2 errors) indicates that 13 tests were run and there were errors for two tests.
Tests
Viewing Available Deployment Connections

A deployment connection enables customizations to be copied from one organization to another. The deployment connections list shows which organizations are authorized to upload changes to this organization, and which organizations allow this organization to upload changes to them. To view available connections, click Your Name | Setup | Deploy | Deployment Connections Action Click Edit next to the organization that you want to allow or disallow change sets from. Name A list of organizations that have deployment connections to the organization you are currently logged into. Click the name of an organization to view more information about the connection. Description A brief description of the connected organizations. Type The type of organization you are connected to. Possible values are Production, Full Copy Sandbox, Configuration-only Sandbox, and Developer Sandbox. Upload Authorization Direction
The arrows show the direction in which uploads can occur. A broken line means that no change sets are authorized in either direction. To authorize the connected organization to send you inbound change sets, edit the deployment connection for this organization. If you want to send outbound change sets to a connected organization, the administrator for that organization must edit the connection for that organization.
Viewing Details of a Deployment Connection

A deployment connection enables customizations to be copied from one organization to another. The deployment connections list shows which organizations are authorized to upload changes to this organization, and which organizations allow this organization to upload changes to them. To view connection details: 1. 2. Click Your Name | Setup | Deploy | Deployment Connections. Click the name of the organization you want to view.
Name The name of the selected organization. This is not the organization you are logged into. Description A brief description of the organization. Type The type of organization you are connected to. Possible values are Production, Full Copy, Configuration-only, and Developer. Allow Inbound Changes If selected, the named organization can send change sets to the organization you are currently logged into. This is a readonly field and can only be modified by selecting Allow Inbound Changes in the target organization. Accepts Outbound Changes If selected, the named organization allows change sets to be sent to it from the organization you are currently logged into.
Authorizing a Deployment Connection

In order for another organization to send change sets to the organization you are logged into, you must authorize the inbound change set: 1. 2. 3. 4. Click Your Name | Setup | Deploy | Deployment Connections. Click Edit next to the organization you want to authorize. Select Allow Inbound Changes. Click Save.
Specific Profile Permissions control what users are able to deploy or upload change sets. In general Customize application permission is required to use these features. Additonal permissions include "Manage Inbound Change Sets" and "Create and Upload Change Sets". Enable to profile permission Manage Inbound Change Sets to allow users in the profile to authorize Deployment Connections to upload change sets, and deploy inbound change set to the org Enable the profile permission Create and Upload Change Sets to allow user to define a change set and upload it to another org via any authorizing Deployment Connection A Sandbox user must also exist in production in order to deploy a Change Set. Change set deployment is not compatible with new users created in sandbox. Make sure the user attempting to Deploy a change set exists in the production instance and is associated to a profile with permissions required to perform the function.
After deploying a Change Set to an organization, newly installed components will appear in Setup for the administrator, but some components may not be automatically appear for users. This can happen because Change Sets do not currently support the uploading or deployment of Profiles, which control the visibility and access levels of some components (i.e. tabs, objects, fields, etc). To allow users to view these component, review their profiles and adjust the visibility and access levels accordingly. For example, if a Custom Tab component was deployed to an organization, and users belonging to the Standard User profile should have access, go to Setup | Manage Users | Profiles | Standard User | Tab Settings | Custom Tab Settings and choose the "Default On" option for the given tab
Deploying Workflow Email Notifications via Changesets changes Recipients value

When we deploying Workflow Email Notifications via Change Sets, the Recipients value get changed. This is expected behavior. Usernames are different in sandbox and production, therefore the value in the change set does not match any user in the org. So the system defaults it to the deploying user. This behavior also exists for Dashboards or anything else where a username is embedded in the metadata files.
Viewing User License Types


To view user license types:
View Setup and Configuration
You may have more than one type of user license in Salesforce. A user license entitles a user to different functionality within Salesforce and determines the profiles available to the user. To view a list of the active user licenses your organization has purchased, click Your Name | Setup | Company Profile | Company Information. This page lists the following for each type of user license:
Status indicates the status of the license. Total Licenses indicates the number of licenses for which your organization is billed and that are available to you. Used Licenses is the number of licenses that you have assigned to users. Remaining Licenses is the number of unused licenses.
You can click Buy More Licenses to go to Checkout to buy additional user licenses. In addition to license types, the following portal login information is listed for organizations that have Customer Portals or partner portals enabled:
Monthly Logins Allotted shows the maximum number of customer or partner portal logins allowed per month. Monthly Logins Used indicates the number of successful logins for all users associated with a customer or partner
portal user license for the month. The lists below cover the functionality a user is entitled to for each type of standard user license.Note You may see other types of licenses listed on this page if your organization has purchased custom user licenses for different types of functionality. Contact salesforce.com for more information.
Salesforce Users
User License Description
Salesforce
Designed for users who require full access to standard CRM and Force.com AppExchange apps. Users with this user
User License
Description
license are entitled to access any standard or custom app. Each license provides additional storage for Enterprise and Unlimited Edition users. For more information, see Monitoring Resources.
Salesforce Platform
Designed for users who need access to custom apps but not to standard CRM functionality. Users with this user license are entitled to use custom apps developed in your organization or installed from Force.com AppExchange. In addition, they are entitled to use core platform functionality such as accounts, contacts, reports, dashboards, documents, and custom tabs. However, these users are not entitled to some user permissions and standard apps, including standard tabs and objects such as forecasts and opportunities. Users with this license can also use Connect Offline.Note Users with a Salesforce Platform user license can only view dashboards if the Running User of the dashboard also has a Salesforce Platform license. They cannot edit or create new dashboards. For Salesforce Platform and Salesforce Platform One license users, the Platform standard app is the only app listed in the Force.com app menu. Users with a Salesforce Platform user license can access all the custom apps in your organization. For a list of the total number of custom apps available in each Edition, see SalesforceEditions and Limits. Each license provides additional storage for Enterprise and Unlimited Edition users. For more information, see Monitoring Resources.
Salesforce Platform Light
Designed for users who need access to custom apps but not to standard CRM functionality. Users with this user license are entitled to the same rights as Salesforce Platform users, except the amount of times the user can log in is limited monthly.Note Users with this user license cannot edit or create new dashboards and can only view dashboards if the Running User of the dashboard also has a Salesforce Platform Light license. Each license provides an additional 1 MB of data storage and 1 MB of file storage, regardless of Salesforce Edition.
Force.com- One App
Designed for users who need access to one custom app but not to standard CRM functionality. Force.com - One App users are entitled to the same rights as Salesforce Platform users, plus they have access to an unlimited number of custom tabs. However, they are limited to the use of one custom app, which is defined as up to 10 custom objects, and they are limited to read-only access to the Accounts and Contacts objects.Note Users with a Force.com - One App user license cannot edit or create new dashboards and can only view dashboards if the Running User of the dashboard also has aForce.com - One App license. Each license provides an additional 1 MB of data storage and 1 MB of file storage, regardless of the Salesforce Edition.
Force.com- Free Designed for users who need access to one custom app but not standard CRM functionality. Force.com - Free users
are entitled to the same rights as Salesforce Platform users, plus they have access to an unlimited number of custom tabs. However, they are limited to the use of one custom app, which is defined as up to 10 custom objects, and they do not have access to Accounts and Contacts objects.Note Users with a Force.com - Free user license cannot edit or create new dashboards and can only view dashboards if the Running User of the dashboard also has a Force.com - Free license. Each license provides an additional 1 MB of data storage and 1 MB of file storage, regardless of the Salesforce Edition.
Ideas and Answers Internal User Content Only User
Designed for internal Salesforce users who only need access to the ideas and answers features. This license allows users to access the Ideas tab, Answers tab, Home tab, and up to three other custom tabs.
Designed for users who only need access to the Content app. This license allows users to access the following tabs: Workspaces, Content, Subscriptions, Ideas, and Home. Each license provides 500 MB of file storage.
User License Knowledge Only User
Description
Designed for users who only need access to the Salesforce Knowledge app. This license provides access to the following tabs: Articles, Article Management, Home, Reports, and custom tabs. The Knowledge Only User license includes a Knowledge Only profile that grants access to the Articles tab via the View Articles user permission. To view and use the Article Management tab, a user's profile must include the Manage Articles permission. For more information, see Setting Up Salesforce Knowledge. Designed for Unlimited, Enterprise, and Professional Edition users that dont have Salesforce licenses but need access to Chatter. These users can access standard Chatter people, profiles, groups, and files. They can't access any Salesforce objects or data.Note You can upgrade a Chatter Free license to a standard Salesforce license at any time, however, you can't convert a standard Salesforce license to a Chatter Free license.
ChatterFree
ChatterOnly
Designed for Unlimited, Enterprise, and Professional Edition users that dont have Salesforce licenses but need access to Chatter. These users have the same access as Chatter Freeusers, plus they can:
View Salesforce accounts and contacts Use Salesforce CRM Content, Salesforce CRM Ideas, and Answers Modify up to ten custom objects Note You must expose the tabs for the standard Salesforce objects that the Chatter Only user profile can access, as they are hidden by default for these users.
Professional Edition organizations must have Profiles enabled to perform these tasks. Contact your sales representative for more information.
Sites Users
Guest User
Designed for public users who access your Force.com sites. Site visitors have access to any information made available in an active public site. The number of Guest User licenses determines the number of sites that you can develop for your organization. You can create one active site for each Guest User license. Enterprise and Unlimited Editions each come with 25 Guest User licenses. Developer and Force.com - Free Editions each come with one Guest User license. See Sites Limits and Billing. Note
You can't purchase additional Guest User licenses. The Authenticated Website User high-volume portal user license is specifically designed to be used
with sites. Because it's designed for high volumes, it should be a cost-effective option to use with sites.
Customer Portal Users

The High Volume Customer Portal User license is designed for contacts who are allowed to log in to your Salesforce Customer Portal to access customer support information. TheAuthenticated Website
High VolumeCustomer PortalUser (Service Cloud
User License
Portal User) and
Description
User license is designed to allow sites users to log in to your Customer Portal. You can associate highvolume portal users with a High Volume Customer Portal User or Authenticated Website User profile, or a profile cloned and customized from one of these. Can access custom objects depending on profile settings. High-volume portal users don't have roles and aren't included in the role hierarchy. They can access records if all of the following conditions are met:
Authenticated Website User

Both user licenses arehigh-volume portal users
They own the record They can access a record's parent, and the organization-wide sharing setting for that record is Controlled by Parent The organization-wide sharing setting for the object is Public Read Only or Public Read/Write The record is the account or contact under which they are enabled (read access only) You can't include high-volume portal users in:
Personal groups or public groups Sharing rules Account teams, sales teams, or case teams Salesforce CRM Content workspaces Users with the High Volume Customer Portal User license can access accounts, assets, cases, contacts, custom objects, documents, ideas, and questions depending on their profile settings. Users with the Authenticated Website User license have read-only access to documents, ideas and questions, as well as full access to custom objects. Contact salesforce.com for information about the number of Customer Portal user licenses you can activate.
Customer Portal Manager Standard
Designed for contacts who are allowed to log in to your Salesforce Customer Portal to access customer support information. You can associate users with a Customer Portal Manager Standard license with the Customer Portal User profile or a profile cloned and customized from the Customer Portal User profile. This lets them view and edit data they directly own or data owned by or shared with users below them in the Customer Portal role hierarchy. These users can also view and edit cases where they are listed in theContact Name field. Users with the Customer Portal Manager Standard license can:
Access custom objects depending on their profile settings Receive the Portal Super User permission Access Salesforce CRM Content if they have a Salesforce CRM Content feature license or a customized profile Contact salesforce.com for information about the number of Customer Portal user licenses you can activate.
Customer Portal Manager Custom
Designed for contacts who are allowed to log in to your Salesforce Customer Portal to access customer support information. You can associate users with a Customer Portal Manager Custom license with the Customer Portal Manager profile or a profile cloned and customized from the Customer Portal Manager profile., which lets them view and edit data they directly own and view and edit cases where they're listed in the Contact Name field. Users with the Customer Portal Manager Custom license can:
Access custom objects and run reports depending on their profile settings Receive the Portal Super User and Delegated Portal User Administrator permissions Access Salesforce CRM Content if they have a Salesforce CRM Content feature license or a customized
User License
Description
profile Contact salesforce.com for information about the number of Customer Portal user licenses you can activate.
Partner Portal Users

Users with a partner user license can only access Salesforce using the partner portal.
User License
Description
Bronze Partner
Users with a Bronze Partner license can access Documents and My Account Profile, but have no storage space.Important The Bronze Partner License is not available for purchase after July 2008. Bronze Partner Licenses that were purchased before July 2008 are still supported.
Silver Partner
Users with a Silver Partner license can access the Documents tab, My Account Profile, Leads, and Approvals, and have 2 MB of data storage space. Access to Salesforce CRM Content is determined by feature license and profile.
Gold Partner
Users with a Gold Partner license can access the Documents tab, My Account Profile, Leads, Custom Objects, Approvals, Accounts, Cases, and Opportunities, and have 5 MB of data storage space. Access to Salesforce CRM Content is determined by feature license and profile.
Viewing Feature Licenses


To view feature licenses:
You may have more than one type of feature license available to assign to the users in your organization. A feature license entitles a user to an additional Salesforce feature, such as Marketing or Connect Offline. To view a list of the feature licenses your organization has purchased, click Your Name | Setup | Company Profile | Company Information. This page lists the following for each type of feature license:
Status indicates the status of the license. Total Licenses indicates the number of licenses for which your organization is billed and that are available to you. Used Licenses is the number of licenses that you have assigned to users. Remaining Licenses is the number of unused licenses.
Additionally, you can click Buy More Licenses to go to Checkout to buy additional feature licenses; see Checkout User Guide for instructions. The following feature licenses are available:
Marketing User Offline User Apex Mobile User Salesforce CRM Content UserNote
In Summer '10, the Salesforce CRM Content feature license is included in all organizations at no additional cost.
Overview of Profiles

To view profiles:
To create, edit, or delete profiles:
Manage Users AND Customize Application
A profile contains the settings and permissions that control what users with that profile can do within Salesforce, the partner portal, and the Customer Portal. Profiles control:
Which standard and custom apps the user can view (depending on user license) Which service providers the user can access Which tabs the user can view (depending on user license and other factors, such as access to Salesforce CRM Content) Which administrative and general permissions the user has for managing the organization and apps within it Which object permissions the user is granted to create, read, edit, and delete records Which page layouts a user sees The field-level security access that the user has to view and edit specific fields Which record types are available to the user Which desktop clients users can access and related options The hours during which and IP addresses from which the user can log in Which Apex classes a user can execute Which Visualforce pages a user can access
There are standard profiles in every Salesforce organization. In Contact Manager, Group, and Professional Edition organizations, you can assign the standard profiles to your users, but you cannot view or edit the standard profiles or create custom profiles. In Enterprise, Unlimited, and Developer Edition organizations, you can use standard profiles, or create, edit, and delete custom profiles. For standard profiles, only certain settings can be changed. Each standard or custom profile belongs to exactly one user license type.
Viewing Profile Lists


To view profiles:
To create, edit, and delete profile list views:
Manage Users
To print a profile list:
A profile contains the settings and permissions that control what users with that profile can do within Salesforce, the partner portal, and the Customer Portal. To view the profiles in your organization, click Your Name | Setup | Manage Users |Profiles.
Viewing Enhanced Profile Lists

If enhanced profile list views are enabled for your organization, you can use additional tools to customize, navigate, manage, and print profile lists. You can also edit permissions directly in a list view.
To show a filtered list of profiles, select a view from the drop-down list. To create a profile, click New Profile, or click Clone next to the profile that you want to base the new profile on. To create a list view, click Create New View. To print a list view, select the view from the drop-down list and click the Printable View button ( To edit a view, select it from the drop-down list and click Edit To delete a view, select it from the drop-down list and click Delete. To refresh the list view after creating or editing a view, click Refresh. To edit a profile, click Edit next to its name. To delete a custom profile, click Del next to its name. To create a new profile based on an existing profile, click Clone next to the profile name. ).
Viewing the Basic Profile List
To create a profile, click New or New Profile. Select an existing profile to clone, name the new profile, and
click Save.Note A new profile uses the same user license as the profile it was cloned from.
To view a profile's details, click its name. To edit a profile, click Edit next to its name. To delete a custom profile, click Del next to its name.
Viewing and Editing Profiles


To view profiles:
To edit profiles:
Viewing and Managing a Profile

To view a profile, click Your Name | Setup | Manage Users | Profiles, then select the profile you want. On the profile detail page, you can do any of the following:
Click Edit to edit the profile settings. Click Clone to create a profile based on this profile.Note
A new profile uses the same user license as the profile it was cloned from.
For custom profiles only, click Delete to delete the profile.
Click View Users to view the users who are assigned to the profile.
Editing a Profile
You can edit all settings in a custom profile. In standard profiles, you can edit all settings except name and description, and object, app, and system permissions. 1. 2. 3. Click Your Name | Setup | Manage Users | Profiles. Select the profile you want to edit. On the profile detail page, click Edit to change any of the following settings:
For custom profiles only, the name and description The standard or custom apps that are visible to users with the profile.Note Every profile must have at least one visible app, except for profiles associated with Customer Portal users because apps are not available to them.
Tab visibility settings For custom profiles only, administrative and general permissions For custom profiles only, standard and custom object permissionsNote Editing some permissions may automatically cause other permissions to be enabled or disabled. For example, enabling View All Data automatically enables Read for all standard and custom objects. Likewise, enabling Transfer Leads automatically enables Read and Create on leads. Tip If enhanced profile list views are enabled for your organization, you can change permissions for multiple profiles from the list view.
Desktop client access settings
You can also view or edit the following settings from the profile detail page: Setting Procedure to View or Edit
Console layouts for all profiles
Under the Console Settings section, click Edit.
Page layouts
Under the Page Layouts section, click View Assignment next to an object name.
Access to fields in each object Under the Field-Level Security section, click View next to an object name.
Record types
Under the Record Type Settings section, click Edit next to a tab name. The Edit link is available only if record types exist for the object.
Login hours
Under the Login Hours section, click Edit.
Login IP address ranges
Under the Login IP Ranges section, click New, or click Edit next to an existing IP range.
Setting
Procedure to View or Edit
Executable Apex classes
Under the Enabled Apex Class Access section, click Edit.
Executable Visualforce pages
Under the Enabled Visualforce Page Access section, click Edit.
Creating and Editing Profile List Views


To create, edit, and delete profile list views:
Manage Users
If enhanced profile list views are enabled for your organization, you can create profile list views to show a set of profiles with the fields you choose. For example, you could create a list view of all profiles in which Modify All Data is enabled.
Creating a Profile List View

1. 2. 3. In the Profiles page, click Create New View. Enter the view name. Under Specify Filter Criteria, specify the conditions that the list items must match, such as Modify All Data equals
True.
a. b. c. d. Type a setting name, or click the lookup icon Choose a filter operator. Enter the value that you want to match. To specify another filter condition, click Add. You can specify up to 25 filter condition rows.Note To remove a filter condition row and clear its values, click the remove row icon 4. the list view. a. b. From the Search drop-down list, select the type of setting you want to search for. Enter part or all of a word in the setting you want to add and click Find.Note If the search finds more than 500 values, no results appear. Use the preceding steps to refine your search criteria and show fewer results. c. d. Note You can add up to 15 columns in a single list view. 5. Click Save. To add or remove columns, select one or more column names and click the Add or Remove arrow. Use the Top, Up, Down, and Bottom arrows to arrange the columns in the sequence you want. . to search for and select the setting you want.
Under Select Columns to Display, specify the profile settings that you want to appear as columns in
Editing a Profile List View

To edit or clone an existing list view:
1. 2. 3. 4.
In the Profiles page, select the view you want from the drop-down list. Click Edit. Edit the fields as described in the procedure for creating a list view. Click Save. To clone an existing view, rename the list view and click Save As.
Editing Profiles Using Profile Lists


To edit multiple profiles from the list view:
Manage Users AND Customize Application AND Mass Edits from Lists
If enhanced profile list views are enabled for your organization, you can change permissions in up to 200 profiles directly from the list view, without accessing individual profile pages. Editable fields display a pencil icon ( ) when you hover over the field, while non-editable fields display a lock icon ( ). In some cases, such as in standard profiles, the pencil icon appears but the setting is not actually editable.
Warning Use care when editing profiles with this method. Because profiles affect a user's fundamental access, making mass changes may have a widespread effect on users in your organization.
To change permissions in one or more profiles: 1. 2. 3. 4. Select or create a list view that includes the profiles and permissions you want to edit. To edit multiple profiles, select the checkbox next to each profile you want to edit. If you select profiles on multiple pages, Salesforce remembers which profiles are selected. Double-click the permission you want to edit. For multiple profiles, double-click the permission in any of the selected profiles. In the dialog box that appears, enable or disable the permission. In some cases, changing a permission may also change other permissions. For example, if Manage Cases and Transfer Cases are enabled in a profile and you disable Transfer Cases, then Manage Cases is also disabled. In this case, the dialog box lists the affected permissions. 5. 6. To change multiple profiles, select All n selected records (where n is the number of profiles you selected). Click Save.
Note
For standard profiles, inline editing is available only for the Single Sign-On and Affected By Divisions permissions. If you edit multiple profiles, only those profiles that support the permission you are changing will change. For example, if you use inline editing to add Modify All Data to multiple profiles and one profile is a platform profile (which doesn't have Modify All Data) the platform profile won't change.
If any errors occur, an error message appears, listing each profile in error and a description of the error. Click the profile name to open the profile detail page. The profiles you've clicked appear in the error window in gray, strike-through text.
Note
To view the error console, pop-up blockers must be disabled for the Salesforce domain. To check if your browser allows pop-up windows, click Your Name | Setup | My Personal Information | Reminders, and then click Preview Reminder Alert.
To review your changes in the setup audit trail, select Your Name | Setup | Security Controls | View Setup Audit Trail.
Enhanced Profile User Interface Overview

Note The enhanced profile user interface is available through a pilot program. To find out if your organization qualifies for the pilot program, contact salesforce.com. Any unreleased services or features referenced in this or other press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make their purchase decisions based upon features that are currently available.
The enhanced profile user interface provides a streamlined experience for managing profiles. With it, you can easily navigate, search, and modify settings for a profile. You can't use the enhanced profile user interface if any of the following are true:
You use Microsoft Internet Explorer 6 or earlier to manage your profiles (unless you've installed the Google Chrome Frame plug-in for Internet Explorer). Your organization has enabled Salesforce as an identity provider (also a pilot program). Your organization uses category groups on guest profiles used for sites.
We appreciate your feedback on the enhanced profile user interface pilot program. Do you have a technical question or a suggestion? Comment on this feature or the documentation at this Ideas page.
Enabling the Enhanced Profile User Interface


To modify user interface settings:
1. 2. 3. Click Your Name | Setup | Customize | User Interface. Select Enable Enhanced Profile User Interface. Click Save.
Working in the Enhanced Profile User Interface Overview Page


To view profiles:
To clone and delete profiles, and edit profile properties:
Manage Users
In the enhanced profile user interface, the profile overview page provides an entry point for all of the settings and permissions for a single profile. To open the profile overview page, click Your Name | Setup | Manage Users | Profiles, and click the profile you want to view. From the profile overview page, you can perform the following tasks on the currently open profile.
Search for an object or permission. Create a profile based on the current profile by clicking Clone. Enter a name and click Save. If it's a custom profile, delete the profile by clicking Delete. Change the profile name or description by clicking Edit Properties. Click Assigned Users to see a list of users who are assigned to the profile. View or edit profile settings for:
o o o o o o o o o
Assigned apps Objects and tabs App permissions Apex class access Visualforce page access System permissions Desktop client access Login hours Login IP ranges
App and System Settings in the Enhanced Profile User Interface

In the enhanced profile user interface, administrators can easily navigate, search, and modify settings for a single profile. Permissions and settings are organized into pages under app and system categories, which reflect the rights users need to administer and use app and system resources.
App Settings
Apps are sets of tabs that users can change by selecting the drop-down menu in the header. All underlying objects, components, data, and configurations remain the same, regardless of the selected app. In selecting an app, users can navigate in a set of tabs
that allows them to efficiently use the underlying functionality for app-specific tasks. For example, let's say you do most of your work in the sales app, which includes tabs like Accounts and Opportunities. To track a new marketing campaign, rather than adding the Campaigns tab to the sales app, you select Marketing from the app drop-down to view your campaigns and campaign members. In the enhanced profile user interface, the Apps section includes the following settings pages:
Assigned Apps Objects and Tabs, which include:
o o o o
Tab Settings Record Types and Page Layout Settings Object Permissions Field Permissions
App Permissions Apex Class Access Visualforce Page Access
These settings are directly associated with the business processes that the apps enable. For example, customer service agents may need to manage cases, so the Manage Cases permission is in the Call Center section of the App Permissions page. Some app settings aren't related to app permissions. For example, to enable the Time-Off Manager app from the AppExchange, users need access to the appropriate Apex classes and Visualforce pages, as well as the object and field permissions that allow them to create new time-off requests.
Note Regardless of the currently selected app, all of a user's permissions are respected. For example, although the Import Leads permission is under the Sales category, a user can import leads even while in the Call Center app. System Settings
Some system functions apply to an organization and not to any single app. For example, login hours and login IP ranges control a user's ability to log in, regardless of which app the user accesses. Other system functions apply to all apps. For example, the Run Reports and Manage Dashboards permissions allow managers to create and manage reports in all apps. In some cases, such as with Modify All Data, a permission applies to all apps, but also includes non-app functions, like the ability to download the Data Loader and empty the organization's recycle bin. In the enhanced profile user interface, the System section includes the following settings pages:
System Permissions Desktop Client Access Login Hours Login IP Ranges
Securing Data Access

The available data management options vary according to which Salesforce Edition you have.
Choosing the data set that each user or group of users can see is one of the key decisions that affects data security. You need to find a balance between limiting access to data, thereby limiting risk of stolen or misused data, versus the convenience of data access for your users. To enable users to do their job without exposing data that they do not need to see, Salesforce provides a flexible, layered sharing design that allows you to expose different data sets to different sets of users.
To specify the objects and tabs that a user can access, you can assign a profile. To specify the fields that a user can access, you can use field-level security.
To specify the individual records that a user can view and edit, you can set your organization-wide sharing settings, define a role hierarchy, and create sharing rules.
Tip When implementing security and sharing rules for your organization, make a table of the various types of users in your organization. In the table, specify the level of access to data that each type of user needs for each object and for fields and records within the object. You can refer to this table as you set up your security model.
The following describes these security and sharing settings: Object-Level Security (Profiles) Object-level security provides the bluntest way to control data in Salesforce. Using object-level security you can prevent a user from seeing, creating, editing, or deleting any instance of a particular type of object, such as a lead or opportunity. Object-level security allows you to hide whole tabs and objects from particular users, so that they do not even know that type of data exists. You specify object-level security settings on profiles. A profile is a collection of settings and permissions that determine what a user can do in the application, similar to a group in a Windows network, where all of the members of the group have the same folder permissions and access to the same software. Profiles are typically defined by a user's job function (for example, system administrator or sales representative), but you can have profiles for anything that makes sense for your organization. A profile can be assigned to many users, but a user can be assigned to only one profile at a time. It is worth spending the necessary time up-front to align your various user sets with profiles, depending on what they need to see and do in the application. Field-Level Security Once you have restricted access to objects as a whole with profiles, you may want to limit access to individual object fields. Field-level security controls whether a user can see, edit, and delete the value for a particular field on an object. It allows you to protect sensitive fields without having to hide the whole object from certain profiles. Field-level security is controlled within profiles. Unlike page layouts, which only control the visibility of fields on detail and edit pages, field-level security controls the visibility of fields in any part of the app, including related lists, list views, reports, and search results. To be absolutely sure that a user cannot access a particular field, it is important to use the field-level security page for a given object to restrict access to the field. There are no other shortcuts that provide the same level of protection for an individual field.Important Field-level security doesn't prevent searching on the values in a field. To set up your organization to prevent users from searching and retrieving records that match a value in a field hidden by field-level security, contact salesforce.com Customer Support. Record-Level Security (Sharing) After setting object- and field-level access permissions for your various profiles, you need to configure the access permissions for the actual records themselves. Record-level security allows you to grant users access to some object records, but not others. Every record is owned by a user or a queue. The owner has full access to the record. Hierarchies allow administrators to ensure that users higher in a hierarchy (such as managers in a role hierarchy) always have access to the data visible to users below them in the hierarchy. This access applies to records owned by users, as well as records shared with them. To specify record-level security, set your organization-wide sharing settings, define a hierarchy, and create sharing rules:
The first step in record-level security is to determine the organization-wide sharing settings for each object. Organizationwide sharing settings specify the default level of access to records and can be set separately for accounts (including assets and contracts), activities, contacts, campaigns, cases, leads, opportunities, calendars, price books, and custom objects. For most objects, organization-wide sharing settings can be set to Private, Public Read Only, or Public Read/Write. You use organization-wide sharing settings to lock down your data to the most restrictive level, and then use the other record-level security and sharing tools (role hierarchies, sharing rules, and manual sharing) to open up the data to other users who need to access it. For example, for users whose profiles allow them to see and view opportunities, you can
set the default to Read-Only. Those users are able to read all opportunity records, but cannot edit any unless they own the record or are granted additional permissions.
The first way you can share access to records is by defining a role hierarchy. Similar to an organization chart, a role
hierarchy represents a level of data access that a user or group of users needs. The role hierarchy ensures that a manager always has access to the same data as his or her employees, regardless of the organization-wide default settings. Role hierarchies do not have to match your organization chart exactly. Instead, each role in the hierarchy should represent a level of data access that a user or group of users needs. You can also use a territory hierarchy to share access to records. A territory hierarchy grants users access to records based on criteria such as zip code, industry, revenue, or a custom field that is relevant to your business. For example, you could create a territory hierarchy in which a user with the North America role has access to different data than users with the Canada and United States roles. Note Although it is easy to confuse profiles with roles, they control two very different things. Profiles control a user's object- and field-level access permissions. Roles primarily control a user's record-level access permissions through role hierarchy and sharing rules.
Sharing rules let you make automatic exceptions to organization-wide sharing settings for particular sets of users to give
them access to records they do not own or cannot normally see. Sharing rules, like role hierarchies, are only used to open up record access to more users, and can never be stricter than your organization-wide default settings. Sharing rules work best when they are defined for a particular set of users that you can determine or predict in advance, rather than a set of users that is frequently changing. A set of users can be a public or personal group, a role, a territory, or a queue. Sometimes it is impossible to define a consistent group of users who need access to a particular set of records. In those situations, record owners can use manual sharing to give read and edit permissions to users who would not have access to the record any other way. Although manual sharing is not automated like organization-wide sharing settings, role hierarchies, or sharing rules, it gives record owners the flexibility to share particular records with users that need to see them. If sharing rules and manual sharing do not give you the control you need, you can also use Apex managed sharing. Apex managed sharing allows developers to use Apex to programmatically share custom objects. When you use Apex managed sharing to share a custom object, only users with the Modify All Data permission can add or change the sharing on the custom object's record, and the sharing access is maintained across record owner changes.
Managing the Sharing Settings

Available in: Professional, Enterprise, Unlimited, and Developer Editions

To set default sharing access:
Using Salesforce, you can control access to data at many different levels. For example, you can control the access your users have to objects by customizing user profiles. Within objects, you can control the access users have to fields using field-level security. To control access to data at the record level, use the sharing settings described below. To view your sharing settings, click Your Name | Setup | Security Controls | Sharing Settings. You can either view all lists at once, or you can use the Manage sharing settings for drop-down list at the top of the page to view only organizationwide defaults and sharing rules for a selected object.
Organization-Wide Defaults
Your organization-wide default sharing settings give you a baseline level of access for each object and enable you to extend that level of access using hierarchies or sharing rules. For example, you can set the organization-wide default for leads to Private if you only want users to view and edit the leads they own. Then, you can create lead sharing rules to extend access of leads to particular users or groups.
Sharing Rules
Sharing rules represent the exceptions to your organization-wide default settings. If you have organization-wide sharing defaults of Public Read Only or Private, you can define rules that give additional users access to records they do not own. You can create sharing rules based on record owner or field values in the record.Tip Sometimes it is impossible to define a consistent group of users who need access to a particular set of records. In those situations, record owners can use manual sharing to give read and edit permissions to users who would not have access to the record any other way. Although manual sharing is not automated like organization-wide sharing settings, role hierarchies, or sharing rules, it gives record owners the flexibility to share particular records with users that need to see them.
Apex Managed Sharing

Apex managed sharing allows developers to use Apex to programmatically share custom objects. When you use Apex managed sharing to share a custom object, only users with the Modify All Data permission can add or change the sharing on the custom object's record, and the sharing access is maintained across record owner changes. For more information on Apex managed sharing, see the Force.com Apex Code Developer's Guide.
Sharing Overrides
When an object is selected in the Sharing Settings page, the page includes a Sharing Overrides related list, which shows any profiles that ignore sharing settings for that object. For each profile, the list specifies the permissions that allow it to override sharing settings. The View All Data and Modify All Data permissions override sharing settings for all objects in the organization, while the object permissions View All and Modify All override sharing settings for the named object. To override sharing settings for specific objects, you can create or edit custom profiles that use the View All and Modify All object permissions. These permissions provide access to all records associated with an object across the organization, regardless of the sharing settings. Before setting these permissions, compare the different ways to control data access.
Other Methods for Allowing Access to Records

In addition to sharing settings, there are a few other ways to allow multiple users access to given records: Map category groups to roles Control access to data categories by mapping them to user roles. See About Category Group Visibility. Queues Queues help your teams manage leads, cases, service contracts, and custom objects. Once records are placed in a queue manually or through an automatic case or lead assignment rule, records remain there until they're assigned to a user or taken by one of the queue members. Any queue member or users above them in the role hierarchy can take ownership of records in a queue. Use queues to route lead, case, and custom object records to a group. Teams For accounts, opportunities, and cases, record owners can use teams to allow other users access to their records. A team is a group of users that work together on an account, sales opportunity, or case. Record owners can build a team for each record that they own. The record owner adds team members and specifies the level of access each team member has to the record, so that some team members can have read-only access and others can have read/write
access. The record owner can also specify a role for each team member, such as Executive Sponsor. In account teams, team members also have access to any contacts, opportunities, and cases associated with an account.Note A team member may have a higher level of access to a record for other reasons, such as a role or sharing rule. In this case, the team member has the highest access level granted, regardless of the access level specified in the team.
Sharing Considerations
Your organization's sharing model gives users access to records they do not own. The sharing model is a complex relationship between role hierarchies, user profiles, sharing rules, and exceptions for certain situations. Review the following notes before setting your sharing model:
Exceptions to Role Hierarchy-based Sharing

Users can always view and edit all data owned by or shared with users below them in the role hierarchy. Exceptions to this include:
An option on your organization-wide default allows you to ignore the hierarchies when determining access to data. For more information on this setting, see Controlling Access Using Hierarchies. Contacts that are not linked to an account are always private. Only the owner of the contact and administrators can view it. Contact sharing rules do not apply to private contacts. Notes and attachments marked as private via the Private checkbox are accessible only to the person who attached them and administrators. Events marked as private via the Private checkbox are accessible only by the event owner. Other users cannot see the event details when viewing the event owners calendar. However, users with the View All Data or Modify All Data permission can see private event details in reports and searches, or when viewing other users calendars.
Managers in the role hierarchy cannot view or edit their subordinate's records if they do not have the Read or Edit user permissions for the type of record. Object permissions are set on a user's profile.
Deleting Records

The ability to delete individual records is controlled by administrators, the record owner, users in a role hierarchy above the record owner, and any user that has been granted Full Access. If the sharing model is set to Public Read/Write/Transfer for cases or leads or Public Full Access for campaigns, any user can delete those types of records.
Adding Related Items to a Record

You must have Read/Write access to a record to be able to add notes or attachments to the record. You must have at least Read access to a record to be able to add activities or other associated records to it.
Adding or Removing Sharing Access Manually
The ability to manually extend the sharing access of individual records is controlled by administrators, the record owner, users in a role hierarchy above the record owner, and any user that has been granted Full Access. See Sharing Accounts, Sharing Campaigns, Sharing Contacts, Sharing Opportunities, Sharing Cases, and Sharing Leads.
Changing your sharing model deletes any manual shares your users have created.
User Permissions and Object-Level Permissions

While your sharing model controls visibility to records, user permissions and object-level permissions control what users can do to those records.
Regardless of the sharing settings, users must have the appropriate object-level permissions. For example, if you share an account, those users can only see the account if they have the Read permission on accounts. Likewise, users who have the
Edit permission on contacts may still not be able to edit contacts they do not own if they are working in a Private sharing model.
Administrators, and users with the View All Data or Modify All Data permissions, have access to view or edit all data.
Account Sharing
To restrict users access to records they do not own that are associated with accounts they do own, set the appropriate access level on the role. For example, you can restrict a user's access to opportunities they do not own yet are associated with accounts they do own using the Opportunity Access option.
Regardless of the organization-wide defaults, users can, at a minimum, view the accounts in their territories. Also, users can be granted access to view and edit the contacts, opportunities, and cases associated with their territories' accounts.
Apex Sharing
You can't change the organization-wide default settings from private to public for a custom object if an Apex script uses the sharing entries associated with that object. For example, if a script retrieves the users and groups who have sharing access on a custom object Invoice__c (represented as Invoice__share in the code), you can't change the object's organizationwide sharing setting from private to public.
Campaign Sharing
In Enterprise, Unlimited, and Developer Editions, designate all users as Marketing Users when enabling campaign sharing. This simplifies administration and troubleshooting because access can be controlled using sharing and profiles.Note Professional Edition customers cannot manage users this way because custom profiles are not enabled in Professional Edition organizations.
a.
To segment visibility between business units while maintaining existing behavior within a business unit: Set the campaign organization-wide default to Private. b. c. Create a sharing rule to grant marketing users Public Full Access to all campaigns owned by users within their business unit. Create a sharing rule to grant all non-marketing users in a business unit Read Only access to all campaigns owned by users in their business unit.
When a single user, such as a regional marketing manager, owns multiple campaigns and needs to segment visibility between business units, share campaigns individually instead of using sharing rules. Sharing rules apply to all campaigns owned by a user and do not allow segmenting visibility.
Create all campaign sharing rules prior to changing your organization-wide default to reduce the affect the change has on your users. To share all campaigns in your organization with a group of users or a specific role, create a sharing rule that applies to campaigns owned by members of the Entire Organization public group. Minimize the number of sharing rules you need to create by using the Roles and Subordinates option instead of choosing a specific role. If campaign hierarchy statistics are added to the page layout, a user can see aggregate data for a parent campaign and all the campaigns below it in the hierarchy regardless of whether that user has sharing rights to a particular campaign within the hierarchy. Therefore, consider your organization's campaign sharing settings when enabling campaign hierarchy statistics. If you do not want users to see aggregate hierarchy data, remove any or all of the campaign hierarchy statistics fields from the Campaign Hierarchy related list. These fields will still be available for reporting purposes. For more information, see Viewing Campaign Hierarchy Statistics.
If the sharing model is set to Public Full Access for campaigns, any user can delete those types of records.
Campaign Member Sharing
Campaign member sharing is controlled by campaign sharing rules. Users that can see a campaign can also see associated campaign members.
Contact Sharing

The organization-wide sharing default for contacts is not available to organizations that have person accounts enabled. If your organization-wide default for contacts is set to Controlled by Parent, the Contact Access options are not available when sharing related records like accounts; instead, all access to contacts is determined by the user's access to the contact's account.
Price Book Sharing

Sharing on price books controls whether users can add the price book and its products to opportunities. User permissions on profiles control whether users can view, create, edit, and delete price books.
Managing Roles

To create, edit, and delete roles:
Manage Users
To assign users to roles:
Manage Users
Depending on your sharing settings, roles can control the level of visibility that users have into your organizations data. Users at any given role level can view, edit, and report on all data owned by or shared with users below them in the hierarchy, unless your organizations sharing model for an object specifies otherwise. Specifically, in the Organization-Wide Defaults related list, if the Grant Access Using Hierarchies option is disabled for a custom object, only the record owner and users granted access by the organization-wide defaults receive access to the object's records.
Note The following information applies to roles for your organization's users. For information about roles for partner users and Salesforce Customer Portal users, see About Partner Portal Channel Manager User Management and About Customer Portal User Management. Working with Roles
To view and manage your organization's roles, click Your Name | Setup | Manage Users | Roles.
Choose one of the following list view options: Show in tree view See a visual representation of the parent-child relationships between your roles. Click Expand All to see all roles, or Collapse All to see only top-level roles. To expand or collapse an individual node, click the plus (+) or minus (-) icon. Show in sorted list view See a list that you can sort alphabetically by role name, parent role (Reports to), or report display name. If your organization has a large number of roles, use this view for easy navigation and filtering. To show a filtered list of items, select a predefined list from the View drop-down list, or click Create New View to define your own custom view. To edit or delete any view you created, select it from the View drop-down list and click Edit. Show in list view
See a list of roles and their children, grouped alphabetically by the name of the top-level role. The columns are not sortable. This view is not available for hierarchies with more than 1,000 roles.
To create a role, click New Role or Add Role, depending whether you are viewing the list view or tree view of roles, then edit the role fields as needed. You can create up to 500 roles for your organization. To edit a role, click Edit next to a role name, then update the role fields as needed. To delete a role, click Delete next to the role name. To assign other users to a role, click Assign next to the role name. To view detailed information about a role, click a role name. If you are a Salesforce Knowledge user, you can modify category visibility settings on the role detail page.
Tip To simplify user management in organizations with large numbers of users, enable delegated administrators to manage users in specified roles and all subordinate roles. Notes on Roles
Every user must be assigned to a role, or their data will not display in opportunity reports, forecast roll-ups, and other displays based on roles. If your organization uses territory management, forecasts are based on the territory hierarchy rather than the role hierarchy.
All users that require visibility to the entire organization should belong to the highest level in the hierarchy. It is not necessary to create individual roles for each title at your company, rather you want to define a hierarchy of roles to control access of information entered by users in lower level roles. When you change a users role, any relevant sharing rules are evaluated to add or remove access as necessary. When an account owner is not assigned a role, the sharing access for related contacts is Read/Write, provided the organization-wide default for contacts is not Controlled by Parent. Sharing access on related opportunities and cases is No Access.
Users that gain access to data due to their position in hierarchies do so based on a setting in your organization-wide defaults.
Comparing Security Models

Salesforce user security is an intersection of sharing, and administrative, general, and object permissions. In some cases, such as in end-user record level access, it is advantageous to use sharing to provide access to records. In other cases, such as when delegating record administration tasks like transferring records, cleansing data, deduplicating records, mass deleting records, and delegating workflow approval processes, it is advantageous to override sharing and use permissions to provide access to records. In permissions for standard and custom objects, the Read, Create, Edit, and Delete permissions respect sharing settings, which control access to data at the record level. The View All and Modify All permissions override sharing settings for specific objects. Additionally, the View All Data and Modify All Data permissions override sharing settings for all objects. The following table describes the differences between the security models.
Permissions that Respect Sharing
Permissions that Override Sharing
Target audience
End-users
Delegated data administrators View All and Modify All
Where managed
Read, Create, Edit, and Delete object permissions; Sharing settings
Record access levels
Private, Read-Only, Read/Write, Read/Write/Transfer/Full Access
View All and Modify All
Permissions that Respect Sharing Ability to transfer Ability to approve records, or edit and unlock records in an approval process Ability to report on all records Respects sharing settings, which vary by object None
Permissions that Override Sharing Available on all objects with Modify All Available on all objects with Modify All
Available with a sharing rule that states: the records owned by Available on all objects with View All the public group Entire Organization are shared with a specified group, with Read-Only access Available on all objects except products, documents, solutions, ideas, notes, and attachments Available on most objects in the Object Permissions sections of profilesNote View All and Modify All are not available for ideas, price books, and products.
Object support
Group access levels determined by
Roles, Roles and Subordinates, Roles and Internal Subordinates, Roles, Internal and Portal Subordinates, Queues, Teams, and Public Groups Not available
Profile
Private record access
Available on private contacts, opportunities, and notes and attachments with View All and Modify All Available on all objects with Modify All
Ability to manually share records Ability to manage all case comments
Available to the record owner and any user above the record owner in the role hierarchy Not available
Available with Modify All on cases
Object Permissions
Available in: All Editions
The following permissions specify the access that users have to standard and custom objects. Object permissions either respect or override sharing rules and settings.
Permission
Description
Respects or Overrides Sharing?
Read
Users can only view records of this type.
Respects sharing
Create
Users can read and create records.
Respects sharing
Edit
Users can read and update records.
Respects sharing
Permission
Description
Respects or Overrides Sharing?
Delete
Users can read, edit, and delete records.
Respects sharing
View All
Users can view all records associated with this object, regardless of sharing settings.
Overrides sharing
Modify All
Users can read, edit, delete, transfer, and approve all records associated with this object, regardless of sharing settings.Note Modify All on documents allows access to all shared and public folders, but not the ability to edit folder properties or create new folders. To edit folder properties and create new folders, users must have the Manage Public Documents permission.
Overrides sharing
In Enterprise, Unlimited, and Developer Editions, when you create a custom object, its object permissions are disabled in most profiles (except in profiles with View All Data or Modify All Data enabled). You can enable custom object permissions in custom profiles.
Note If your organization has deployed Salesforce Mobile, you can edit the mobile object properties to prevent mobile users from creating, editing, and deleting records in the mobile application, regardless of their standard object permissions in Salesforce.
Setting Your Organization-Wide Sharing Defaults


1. 2. 3. 4.
Click Your Name | Setup | Security Controls | Sharing Settings. Click Edit in the Organization-Wide Defaults area. For each object, select the default access you want. To disable automatic access using your hierarchies, deselect Grant Access Using Hierarchies for any custom object that does not have a default access of Controlled by Parent.Note If Grant Access Using Hierarchies is deselected, users that are higher in the role or territory hierarchy don't receive automatic access. However, some userssuch as those with the View All and Modify All object permissions and the View All Data and Modify All Data system permissionscan still access records they don't own.
Limitations
You can't change the organization-wide sharing default setting for some objects:
Solutions are always Public Read/Write. Service contracts are always Private. The ability to view or edit a document, report, or dashboard is based on a user's access to the folder in which it's stored. Users can only view the forecasts of other users who are placed below them in the role hierarchy, unless forecast sharing is enabled. For more information, see Manually Sharing a Forecast. When a custom object is on the detail side of a master-detail relationship with a standard object, its organization-wide default is set to Controlled by Parent and it is not editable. You can't change the organization-wide default settings from private to public for a custom object if an Apex script uses the sharing entries associated with that object. For example, if a script retrieves the users and groups who have sharing access on a custom object Invoice__c (represented as Invoice__share in the code), you can't change the object's organizationwide sharing setting from private to public
Sharing Default Access Settings


Manage Users
You can use organization-wide defaults to set the default level of record access for the following objects.
Accounts and their associated contracts and assets Activities Calendars Campaigns Cases Contacts Custom objects Leads Opportunities Price books Service contracts
You can assign the following access levels to accounts, campaigns, cases, contacts, contracts, leads, opportunities, and custom objects.
Field
Description
Controlled by Parent
A user can perform an action (such as view, edit, or delete) on a contact based on whether he or she can perform that same action on the record associated with it. For example, if a contact is associated with the Acme account, then a user can only edit that contact if he or she can also edit the Acme account.
Private
Only the record owner, and users above that role in the hierarchy, can view, edit, and report on those records. For example, if Tom is the owner of an account, and he is assigned to the role of Western Sales, reporting to Carol (who is in the role of VP of Western Region Sales), then Carol can also view, edit, and report on Toms accounts.
Public Read Only
All users can view and report on records but not edit them. Only the owner, and users above that role in the hierarchy, can edit those records.
Field
Description
For example, Sara is the owner of ABC Corp. Sara is also in the role Western Sales, reporting to Carol, who is in the role of VP of Western Region Sales. Sara and Carol have full read/write access to ABC Corp. Tom (another Western Sales Rep) can also view and report on ABC Corp, but cannot edit it.
Public Read/Write
All users can view, edit, and report on all records. For example, if Tom is the owner of Trident Inc., all other users can view, edit, and report on the Trident account. However, only Tom can alter the sharing settings or delete the Trident account.
Public Read/Write/Transfer
All users can view, edit, transfer, and report on all records. Only available for cases or leads. For example, if Alice is the owner of ACME case number 100, all other users can view, edit, transfer ownership, and report on that case. But only Alice can delete or change the sharing on case 100.
Public Full Access
All users can view, edit, transfer, delete, and report on all records. Only available for campaigns. For example, if Ben is the owner of a campaign, all other users can view, edit, transfer, or delete that campaign.
Note To use cases effectively, set the organization-wide default for Account, Contact, Contract, and Asset to Public Read/Write.
You can assign the following access levels to personal calendars.
Field
Description
Hide Details
Others can see whether the user is available at given times, but can not see any other information about the nature of events in the users calendar.
Hide Details and Add Events
In addition to the sharing levels set by Hide Details, users can insert events in other users calendars.
Show Details
Users can see detailed information about events in other users calendars.
Show Details and Add Events
In addition to the sharing levels set by Show Details, users can insert events in other users calendars.
Full Access
Users can see detailed information about events in other users calendars, insert events in other users calendars, and edit existing events in other users calendars.
Note Regardless of the organization-wide defaults that have been set for calendars, all users can invite all other users to events.
You can assign the following access levels to price books.
Field
Description
Use
All users can view price books and add them to opportunities. Users can add any product within that price book to an opportunity.
View
All users can view and report on price books but only users with the Edit permission on opportunities or users that have been
Field Only
Description
manually granted use access to the price book can add them to opportunities.
No Access
Users cannot see price books or add them to opportunities. Use this access level in your organization-wide default if you want only selected users to access selected price books. Then, manually share the appropriate price books with the appropriate users. For information on manually sharing a price book to your users, see Sharing Price Books.
You can assign the following access levels to activities.
Field
Description
Private
Only the activity owner, and users above the activity owner in the role hierarchy, can edit and delete the activity; users with read access to the record to which the activity is associated can view and report on the activity.
Controlled by Parent
A user can perform an action (such as view, edit, transfer, and delete) on an activity based on whether he or she can perform that same action on the records associated with the activity. For example, if a task is associated with the Acme account and the John Smith contact, then a user can only edit that task if he or she can also edit the Acme account and the John Smith record.
Controlling Access Using Hierarchies


To change the Grant Access Using Hierarchies option:
Beyond setting the organization-wide sharing defaults for each object, your organization can specify whether users have access to the data owned by or shared with their subordinates in the hierarchy. For example, hierarchies like the role hierarchy or territory hierarchy automatically grant record access to users above the record owner in the hierarchy. The Grant Access Using Hierarchies option in the organization-wide defaults determines the access users have to records that they do not own, including records they do not have sharing access to but someone below them in the hierarchy does. By default, the Grant Access Using Hierarchies option is enabled for all objects, and it can only be changed for custom objects. To control sharing access using hierarchies for any custom object, click Your Name | Setup | Security Controls | Sharing Settings and Edit in the Organization Wide Defaults section. Deselect Grant Access Using Hierarchies if you want to prevent users from gaining automatic access to data owned by or shared with their subordinates in the hierarchies.
Implementation Notes
Regardless of your organization's sharing settings, users can gain access to records they do not own through other means such as user permissions like View All Data, sharing rules, or manual sharing of individual records.
The Grant Access Using Hierarchies option is always selected on standard objects and is not editable. If you disable the Grant Access Using Hierarchies option, sharing with a role or territory and subordinates only shares with the users directly associated with the role or territory selected. Users in roles or territories above them in the hierarchies will not gain access.
If your organization disables the Grant Access Using Hierarchies option, activities associated with a custom object are still visible to users above the activitys assignee in the role hierarchy. If a master-detail relationship is broken by deleting the relationship, the former detail custom object's default setting is automatically reverted to Public Read/Write and Grant Access Using Hierarchies is selected by default. The Grant Access Using Hierarchies option affects which users gain access to data when something is shared with public groups, personal groups, queues, roles, or territories. For example, the View All Users option displays group members and people above them in the hierarchies when a record is shared with them using a sharing rule or manual sharing and the Grant Access Using Hierarchies option is selected. When the Grant Access Using
Hierarchies option is not selected, some users in these groups no longer have access. The following list covers the access reasons that depend on the Grant Access Using Hierarchies option.
These reasons always gain access: Group Member Queue Member Role Member Member of Subordinate Role Territory Member Member of Subordinate Territory These reasons only gain access when using hierarchies: Manager of Group Member Manager of Queue Member Manager of Role Manager of Territory User Role Manager of Territory
Best Practices
When you deselect Grant Access Using Hierarchies, notify users of the changes in report results that they can expect due to losing visibility of their subordinates' data. For example, selecting My team's... in the View drop-down list returns records owned by the user; it will not include records owned by their subordinates. To be included in this type of report view, records from subordinates must be explicitly shared with that user by some other means such as a sharing rule or a manual share. So, if no records are shared with you manually, the My... and My team's... options in the View drop-down list return the same results. However, choosing the Activities with... any custom object report type when creating a custom report returns activities assigned to you as well as your subordinates in the role hierarchy
Comparing Security Models

Salesforce user security is an intersection of sharing, and administrative, general, and object permissions. In some cases, such as in end-user record level access, it is advantageous to use sharing to provide access to records. In other cases, such as when delegating record administration tasks like transferring records, cleansing data, deduplicating records, mass deleting records, and delegating workflow approval processes, it is advantageous to override sharing and use permissions to provide access to records. In permissions for standard and custom objects, the Read, Create, Edit, and Delete permissions respect sharing settings, which control access to data at the record level. The View All and Modify All permissions override sharing settings for specific objects. Additionally, the View All Data and Modify All Data permissions override sharing settings for all objects. The following table describes the differences between the security models.
Permissions that Respect Sharing
Permissions that Override Sharing
Target audience
End-users
Delegated data administrators View All and Modify All
Where managed
Read, Create, Edit, and Delete object permissions; Sharing settings
Record access levels Ability to transfer Ability to approve records, or edit and unlock records in an approval process Ability to report on all records
Private, Read-Only, Read/Write, Read/Write/Transfer/Full Access Respects sharing settings, which vary by object None
View All and Modify All Available on all objects with Modify All Available on all objects with Modify All
Available with a sharing rule that states: the records owned by Available on all objects with View All the public group Entire Organization are shared with a specified group, with Read-Only access Available on all objects except products, documents, solutions, ideas, notes, and attachments Available on most objects in the Object Permissions sections of profilesNote View All and Modify All are not available for ideas, price books, and products.
Object support
Group access levels determined by
Roles, Roles and Subordinates, Roles and Internal Subordinates, Roles, Internal and Portal Subordinates, Queues, Teams, and Public Groups Not available
Profile
Private record access
Available on private contacts, opportunities, and notes and attachments with View All and Modify All Available on all objects with Modify All
Ability to manually share records Ability to manage all case comments
Available to the record owner and any user above the record owner in the role hierarchy Not available
Available with Modify All on cases
What are Data Categories?


To view the Data Categories page: To create, edit, or delete data categories: View Data Categories Manage Data Categories
Data categories can be used by Salesforce Knowledge (articles and article translations) and answers communities (questions) to help users classify and find articles or questions. Administrators can use data categories to control access to articles and questions. Salesforce Knowledge supports a five-level hierarchy of data categories within each category group. Articles in the knowledge base can be classified according to multiple categories that make it easy for users to find the articles they need. For example, to classify articles by sales regions and business units, create two category groups, Sales Regions and Business Units. The Sales Regions category group could consist of a geographical hierarchy, such as All Sales Regions as the top level, North America, Europe, and Asia at the second level, and so on. In an answers community, data categories help organize questions for easy browsing. Each community supports one category group. For example, if you're a computer manufacturer you might create a Products category group that has four sibling categories: Performance Laptops, Portable Laptops, Gaming Desktops, and Enterprise Desktops. On the Answers tab, community members can assign one of the four categories to each question and then browse these categories for answers to specific questions.
Benefits of Data Categories

Logical Classification of Articles As a knowledge base administrator, you can organize your knowledge base articles into a logical hierarchy and tag articles with the attributes that are significant to your business. Easy Access to Questions As an answers community administrator, you can choose which data categories are visible on the Answers tab. Community members can tag a question with a category, which makes finding questions and answers easier for other members. Role-Based Control of Article and Question Visibility As a knowledge base or answers community administrator, you can centrally control the visibility articles or questions by mapping roles in the role hierarchy to categories in the category groups. When an article or question is categorized, users in mapped roles can automatically see it. Article Filtering As a support agent, when articles are classified into logical categories, you can quickly and easily locate the article you need by filtering your organization's knowledge base. To ensure you see all relevant articles, filtering by category has expansive results that include a category's upward and downward relatives in the category hierarchy. For example, if your category hierarchy for products has the levels All Products > Computers > Laptops > Gaming Laptops and you are helping a customer with a laptop problem, filtering by Laptops returns articles classified with Laptops as well as articles classified with Computers, All Products, or Gaming Laptops. Effectively, you are made aware of useful related articles like a free shipping offer for all products or an upgrade offer for gaming laptops. (To prevent irrelevant results, category filtering doesn't return nonlineal relatives like siblings and cousins. Articles about Desktops, a sibling of Laptops, would not display.) Article and Question Navigation As an end user, you can navigate the categories on the Articles tab or Answers tab to find the information you need to solve your problem. Managing Category Groups for Articles and Questions If your organization has Salesforce Knowledge and an answers community, you can create separate category groups or use the same category group for articles and questions.
Overview of Data Categories in Articles

A category group is the container for a set of categories. In Salesforce Knowledge it corresponds to the name of the category dropdown menus. For example, if you use the Data Categories setup page (Your Name | Setup | Customize | Data Categories) to create and activate a category group called Products, a Products menu displays on the Article Management tab, the article edit page, the Articles tab in all channels, and the public knowledge base.
As an illustration, the figure below shows a knowledge base administrator's view of an article about laptop deals; using the article edit page, the administrator has classified the article with Laptops in the Products category group, and USA in the Geography category group. An Article About Laptop Deals on the Article Management Tab
The next figure now illustrates an agent finding that same article published on the Articles tab; the agent has selected Laptops and USA respectively in the Products and Geography drop-down menus to retrieve an article that is classified with both Laptops and USA. An Article About Laptop Deals on the Articles Tab
When you add categories to a category group, you build a hierarchy that can contain up to five levels of depth and up to 100 categories total. Each category can have one parent, many siblings, and many children. A robust and well-organized category hierarchy helps users find the articles that are relevant to them quickly and easily. By default, all Salesforce Knowledge users with a role have access to all categories; however, you can restrict category visibility by role.
Overview of Data Categories in Answers Communities

An answers community supports one category group, and community members can assign one category to each question. Even though you can create up to five hierarchy levels of categories in a category group, only the first level of categories is supported in your answers community. Child categories below the first level are not displayed in the community, and community members can't assign these child categories to questions. The categories within the group display on the Answers tab below the community name.
Answers tab displaying categories
By default, all community members have access to all categories; however, you can specify category visibility by role.
Implementation Tips
Consider the following information when planning and implementing data categories for your organization:
You can create up to three category groups with a maximum of five hierarchy levels in each group. Each category group can contain a total of 100 categories. To increase these limits, contact salesforce.com. If you want to use data categories in an answers community, after creating your category group you must assign it to a community at Your Name | Setup | Customize | Answers | Data Category Assignments. You can only assign one category group to an answers community. Salesforce Knowledge supports multiple category groups.
Even though you can create up to five hierarchy levels of categories in a category group, only the first level of categories is supported in your answers community. Child categories below the first level are not displayed in the community, and community members can't assign these child categories to questions. Salesforce Knowledge supports a hierarchy of data categories.
Category groups are hidden from users until they are activated. Do not activate a category group until you have finished defining its categories and their access settings, including their mapping to roles. When assigning categories to articles, you can choose up to 10 categories in a category group. If an article has no categories, it displays only when you choose the No Filter option in the category drop-down menu. When searching for articles or article translations, selecting a category automatically includes the parent and children of that category and any grandparents, up to and including the top level. Sibling categories are not included. For example, if a category hierarchy has the levels All Products, Switches, Optical Networks, and Metro Core, selecting Optical Networks from the category drop-down menu returns articles assigned to any of the four categories. However, if the Switches category has a sibling category called Routers, selecting Optical Networks does not return articles classified within Routers. Category visibility settings may limit the specific articles you can find.
Once role-based visibility settings have been chosen for the categories:
o o o
Users who are not assigned to a role can only see uncategorized articles and questions unless default category visibility has been set up. By default Customer Portal users and partner portal users inherit the category group visibility settings assigned to their account managers. You can change the category group visibility settings for each portal role. If you only have access to one category in a category group, the category drop-down menu for that category group does not display on the Articles tab.
Deleting a category:
o o
Permanently removes it. It cannot be restored. It never appears in the Recycle Bin. Permanently deletes its child categories.
o o o
As applicable, removes the category and its children from the Answers tab, the Article Management tab, the Articles tab in all channels, and your company's public knowledge base. Removes associations between the category and articles or questions. You can reassign articles and questions to another category. Removes its mapping to a role. Users in the role lose their visibility to articles and answers associated with the deleted category.
Deleting a category group:
Moves it to the Deleted Category Groups section, which is a recycle bin. You can view items in this section but not edit them. It holds category groups for 45 days before they are permanently erased and cannot be recovered. During the 45day holding period, you can either restore a category group, or permanently erase it immediately.
o o o o
Deletes all categories within that group. Removes all associations between the group's categories and articles or questions. Removes all associations between the group's categories and roles. As applicable, removes the category drop-down menu from the Articles tab in all channels, the Article Management tab, and your company's public knowledge base.
You can translate the labels of categories and category groups using the Translation Workbench.
Best Practices
Consider the following tips when using data categories:
To quickly manage data categories, use keyboard shortcuts. After creating or updating categories, set up category group visibility rules. Save your changes frequently. The more actions you perform before clicking Save, the longer it takes to save.
About Category Group Visibility


To view role details: To edit and delete roles: To view users: To edit users: To view categories: View Setup and Configuration Manage Users View Setup and Configuration Manage Users
View Data Categories In organizations that do not use roles, all data categories are visible. Once a role hierarchy is created, category group visibility determines the individual data categories, categorized articles, and categorized questions that a user can see. There are two types of visibility:
Role-based category visibility Default category visibility
Role-based category visibility restricts access to categorized articles and questions by mapping data categories to roles. Users can only see the data categories permitted by their role. If your organization uses roles but does not assign one to every user, default category visibility allows you to provide category visibility to users without roles. For example, although high-volume portal users don't have roles, they can view categorized articles and questions if the associated categories are visible by default.
Enforcement of Visibility Settings

To ensure that users obtain a wide range of relevant information, category group visibility is broadly interpreted. Setting a category as visible makes that category and its entire directly related family lineancestors, immediate parent, primary children, other descendantsvisible to users. For example, consider a Geography category group with continents such as Asia and Europe at the top level, various countries at the second level, and cities at the third level. If France is the only visible category selected, then you
can see articles classified with Europe, France, and all French cities. In other words, you can see categories that have a direct vertical relationship to France but you cannot see articles classified at or below Asia and the other continents.Note Only the first-level categories in the category group are visible on the Answers tab. In the Geography example, only the continent categories appear on the Answers tab; therefore, if France is the category selected as visible in category group visibility settings, community members can see questions classified with Europe. Category group visibility settings are enforced on the Answers tab, the Article Management tab, the Articles tab in all channels (internal app, partner portal, and Customer Portal), and the public knowledge base. In the following areas, users only see the categories that their visibility settings allow:
On the Article Management tab, when creating or editing articles On the Article Management tab and the Articles tab, the category drop-down menu for finding articles On the Answers tab, the categories listed below the community name
Initial Visibility Settings

If roles have not been set up, all users can see all data categories. If a role hierarchy exists but the category group visibility settings have not been modified, all roles have access to all data categories. Users who are not assigned to a role only see uncategorized articles and questions unless you make the associated categories visible by default. Role-based visibility settings restrict default visibility settings; in other words, even if a data category is visible by default, it cannot be seen by a user whose role restricts access to that data category.
Inheritance of Role-Based Visibility Settings

Child roles inherit their parent role's settings and are kept in sync with changes to the parent role. You can customize and reduce the child role's visibility, but you cannot increase it to be greater than that of the parent role. By default, Customer Portal users and partner portal users inherit the category group visibility settings assigned to their account managers. You can change the category group visibility settings for each portal role. Because high-volume portal users don't have roles, you must designate default visibility settings before these users can view categorized articles and questions.
Visibility of Categorized Articles

A user can see an article if he or she can see at least one category per category group on the article. For example, consider an article that is classified with California and Ohio in the Geography category group and Desktop in the Products category group:
If you have visibility on Ohio and Desktop (but not California), you can see the article. If you don't have visibility on either California or Ohio but do have visibility on Desktop, you do not see the article. If you have visibility on California but not Desktop, you do not see the article.
Revoked Visibility
A role's visibility can be revoked (set to None) for a particular category group. Users in the target role can only see articles and questions that aren't classified with a category in that category group. For example, if a user's role has revoked visibility in the Geography category group but visibility to the Products category group, he or she can only see articles that have no categories in Geography and are classified with a category in Products. Because an answers community can only be assigned to one category group, if the Geography category group was assigned to the community and a member's role visibility was revoked for that group, the member could only see uncategorized questions.
Editing Role-Based Category Group Visibility


To view role details: To edit and delete roles: To view users: To edit users: View Setup and Configuration Manage Users View Setup and Configuration Manage Users

To view categories: View Data Categories
Watch a Demo (2 minutes) In organizations that do not use roles, all data categories are visible. Once a role hierarchy is created, category group visibility determines the individual data categories, categorized articles, and categorized questions that a user can see. There are two types of visibility:
Role-based category visibility restricts access to categorized articles and questions by mapping data categories to roles. Users can only see the data categories permitted by their role. If your organization uses roles but does not assign one to every user, default category visibility allows you to provide category visibility to users without roles. For example, although high-volume portal users don't have roles, they can view categorized articles and questions if the associated categories are visible by default. To edit a role's category group visibility setting: 1. 2. 3. Click Your Name | Setup | Manage Users | Role and select a role. If the role is for a Customer Portal or partner portal user, click Your Name | Setup | Manage Users | Users and click the name of the role. In the Category Group Visibility Settings related list, click Edit next to the category group you want to modify. Alternatively, click the name of a category group and then click Edit. Select a visibility setting:
Visibility Setting
Description
All
Users can see all categories in the category group. This option is only available for the topmost role in the role hierarchy. When you create a new category group, its visibility is defaulted to All for the topmost role in the role hierarchy, and all subordinate roles inherit that setting.
Inherited from... None Custom
The role inherits its parent role's visibility settings. If the parent role's settings change, the child role stays in sync. Click the name of the parent role to see its category group visibility settings.
Users cannot see any categories in the category group.
Users see your custom selection of categories. You can choose from the categories that are visible to the parent role. If the parent role's visibility changes to be less than its child's visibility, the child role's category visibility is reset to its parent's category visibility. To select categories, double-click the category in the Available
Categories box.
Alternatively, select a category and then click Add. Selecting a category implicitly includes its child and parent categories as well. Categories that are grayed out in the All Categories box are not available for selection because their parent has already been selected. Note If you are customizing a role that was previously set to All Categories, you must first remove All from the Selected specific categories.
Categories box before you can select
4.
Click Save.
Implementation Tips
When you create a new category group, its visibility is defaulted to subordinate roles inherit that setting.
All for the topmost role in the role hierarchy, and all
When you add a category to a role's visibility, you also grant visibility to its child and parent categories. If you want to give a role access to all categories in a branch of the category hierarchy, select the top level category All Categories. Users who are not assigned to a role can only see uncategorized articles and questions unless:
o o
The user is an administrator who has the View all Data profile permission A category group has been made visible to all no-role users on the Your Name | Setup | Customize | Data Categories | Category Group Visibility page.
By default, Customer Portal users and partner portal users inherit the role assigned to their account managers. You can change the category group visibility settings for each portal role.
Best Practices
Keep your category groups deactivated to set up your category hierarchy and assign role-based category visibility. Until you manually activate a category group, it does not display in Salesforce Knowledge or your answers community Always set up category group visibility in a top-down approach from the top of the role hierarchy down to the bottom. Give the highest roles the most visibility and give subordinate roles reduced visibility.
Modifying Default Data Category Visibility


To view categories: To manage data categories: To assign default category groups: View Data Categories Manage Data Categories
Manage Data Categories In organizations that do not use roles, all data categories are visible. Once a role hierarchy is created, category group visibility determines the individual data categories, categorized articles, and categorized questions that a user can see. There are two types of visibility:
Role-based category visibility restricts access to categorized articles and questions by mapping data categories to roles. Users can only see the data categories permitted by their role. If your organization uses roles but does not assign one to every user, default category visibility allows you to provide category visibility to users without roles. For example, although high-volume portal users don't have roles, they can view categorized articles and questions if the associated categories are visible by default. To modify the default visibility for data categories: 1. 2. 3. 4. Click Your Name | Setup | Customize | Data Categories | Default Data Category Visibility. All active and inactive category groups are listed. Pick a category group and click Edit. Choose All to make all the categories in the category group visible by default, None to make none of the categories visible by default, or Custom to make some of the categories visible by default. If you chose Custom, move categories from the Available Categories area to the Selected Categories area as needed. Selecting a category implicitly includes its child and parent categories as well. Move categories from the Selected Categories area back to the Available Categories area to remove default visibility. For important information about how visibility settings are applied, see About Category Group Visibility.
Viewing Category Group Visibility on Roles


To view role details: To edit and delete roles: To view users: To edit users: To view categories: View Setup and Configuration Manage Users View Setup and Configuration Manage Users
View Data Categories In organizations that do not use roles, all data categories are visible. Once a role hierarchy is created, category group visibility determines the individual data categories, categorized articles, and categorized questions that a user can see. There are two types of visibility:
Role-based category visibility restricts access to categorized articles and questions by mapping data categories to roles. Users can only see the data categories permitted by their role. If your organization uses roles but does not assign one to every user, default category visibility allows you to provide category visibility to users without roles. For example, although high-volume portal users don't have roles, they can view categorized articles and questions if the associated categories are visible by default. To understand the settings and their impact, see About Category Group Visibility.
Viewing a Role's Category Group Visibility

To view a role's category visibility setting, click Your Name | Setup | Manage Users | Roles, and select a role. To view the category visibility settings for a Customer Portal or partner portal role, click Your Name | Setup | Manage Users | Users and click the name of the role. The Category Group Visibility Settings related list summarizes which categories users in the role can see, according to category group. The following table explains the possible values in the Visibility column of the related list:
Visibility
Description
Users can see all categories in the category group. This option is only available for the topmost role in the role hierarchy. When you create a new category group, its visibility is defaulted to role hierarchy, and all subordinate roles inherit that setting.
All
All for the topmost role in the
Inherited from... None Custom
The role inherits its parent role's visibility settings. If the parent role's settings change, the child role stays in sync. Click the name of the parent role to see its category group visibility settings. Users cannot see any categories in the category group. Users can view a selection of categories in the category group.
In the Category Group Visibility Settings related list, you can:
Click a category group to view its setting details. Click Edit next to a category group to modify its visibility settings.
Examples of Category Group Visibility Settings for Articles

Available in: Enterprise, Unlimited, and Developer Editions In organizations that do not use roles, all data categories are visible. Once a role hierarchy is created, category group visibility determines the individual data categories, categorized articles, and categorized questions that a user can see. There are two types of visibility:
Role-based category visibility restricts access to categorized articles and questions by mapping data categories to roles. Users can only see the data categories permitted by their role. If your organization uses roles but does not assign one to every user, default category visibility allows you to provide category visibility to users without roles. For example, although high-volume portal users don't have roles, they can view categorized articles and questions if the associated categories are visible by default. These examples are based on two sample category groups, Products and Geography:Note Although category group visiblity settings are available with answers communities (questions) and Salesforce Knowledge (articles), the examples below apply to articles only. Answers communities support one category group and one data category per question. Products Category Group
All Products o Consumer Electronics Cameras Audio Printers o Enterprise Electronics Routers Switches PEX o Computers Laptops Desktops PDAs
Geography Category Group
All Countries o Americas USA Canada Brazil o Asia China Japan India o Europe France United Kingdom Poland Example 1: A Role Hierarchy
In this example, the Acme Electronics organization manufactures hardware and provides customer support for both consumers and enterprises. The Engineering department is organized by products. The Support department is organized geographically. Europe and the Americas are managed by corporate teams, but Asia is outsourced. Within the corporate and outsourced teams, there are subteams dedicated either to consumer or enterprise support. The table below shows the categories visible to each role in the Acme Electronics organization, and states whether the visibility settings are inherited from the parent role or custom.
Acme Electronics Role Hierarchy

CEO
Visible Geographic Categories
Visible Product Categories
All Countries
All Products
Acme Electronics Role Hierarchy

VP of Engineering
Visible Geographic Categories
Visible Product Categories

All Products Inherit from CEO Consumer Electronics Custom Enterprise Electronics Custom Computers Custom All Products Inherit from CEO All Products Inherit from VP of Support Consumer Electronics, Computers Custom Enterprise Electronics, Computers Custom All Products Inherit from VP of Support Consumer Electronics, Computers Custom Enterprise Electronics, Computers Custom
All Countries Inherit from CEO
Consumer Engineering Team Enterprise Engineering Team Computers Engineering Team VP of Support
All Countries Inherit from VP of Engineering All Countries Inherit from VP of Engineering All Countries Inherit from VP of Engineering All Countries Inherit from CEO
VP of Corporate Support
Europe, America Custom
Director of Corporate Consumer Support Director of Corporate Enterprise Support Outsourced Support
Europe, America Inherit from VP of Corporate Support Europe, America Inherit from VP of Corporate Support Asia Custom
Consumer Support Team
Asia Inherit from Outsourced Support
Enterprise Support Team
Asia Inherit from Outsourced Support
Example 2: Article Visibility

The table below is an in-depth example of how category visibility settings restrict what users see. This example has three sample users whose category settings are noted in parentheses.
Table 1. Example: How Category Visibility Settings Restrict What Users See
Categories When User 1's visibility isAll countries/Computers, the category is:
VISIBLE VISIBLE VISIBLE NOT VISIBLE
When User 2's visibilty isAmerica/All products, the category is:

VISIBLE VISIBLE VISIBLE NOT VISIBLE
When User 3's visibility is France/None, the category is:

NOT VISIBLE NOT VISIBLE NOT VISIBLE NOT VISIBLE
All countries/Laptop Canada/Computers USA/All products Europe/Switches
Table 1. Example: How Category Visibility Settings Restrict What Users See
Categories When User 1's visibility isAll countries/Computers, the category is:
VISIBLE
When User 2's visibilty isAmerica/All products, the category is:

NOT VISIBLE
When User 3's visibility is France/None, the category is:

VISIBLE
Europe/No Categories
User 1: The user's role must be granted visibility in each category that classifies the article, or each category that classifies the article must be visible by default.In this example, User 1 can see Europe, because Europe is the child of All Countries, but he cannot see Switches, because Switches does not belong to Computers. That's why User 1 cannot see articles classified with Europe/Switches. User 2: When a category is made visible to a role or is made visible by default, its child and parent categories are implicitly included; therefore, User 2 can see articles categorized with All Countries because it is the parent category of America. He can also see Articles classified with USA because it is the child of America. User 3: If a role has no access to the whole category group, he can only see articles that are not categorized in that group. User 3 cannot see the articles categorized with All countries/Laptop because he has no visibility in the category group that includes Laptop, but he can see articles categorized with Europe/No categories.
How to access the record type field in a formula field? At this time, you are unable to select the record type field when building a formula field. This feature is on our product roadmap, however there is a work around which will allow a regular picklist field to always display the record type of a record. You can then build your formula field using that picklist field. Here's how you do it: 1. Create a picklist field with each value of the picklist reflecting each record type you have. Call the field "RecordType" and for this example lets say you have two record types: "services" and "software". "Services" and "Software" would be the two selectable options on the picklist "RecordType" that you just created. 2. Go into each Record type - in each one you're able to select with picklist values are displayed for each record type. For the "RecordType" field, set it so only the one picklist value for the record type is displayed for the record type. So, Services would only have the "Services" picklist value. While you're doing that, be sure that you set the "default" picklist value for each record type to be that one remaining value. So "Services" will be the only picklist value for the "RecordType" field when "Services" is the Record type. 3. Finally, on the page layout, make the "RecordType" field required. Now the field will auto populate when a new record is created, users won't be able to override it, and you can use the "RecordType" field for your formula field. A caveat is that this will work for all NEW records that are created. For existing records, you will have to go through and set that field so it works retroactively. You can use the Force.com AppExchange Data Loader to do this.
Creating Apex Sharing Reasons


To create Apex sharing reasons:
Author Apex
To view Apex sharing reasons:
When creating Apex managed sharing, create Apex sharing reasons for individual custom objects to indicate why sharing was implemented, simplify the coding required to update and delete sharing records, and share a record multiple times with the same user or group using different Apex sharing reasons.
Note For more information on Apex managed sharing, see the Force.com Apex Code Developer's Guide.
Salesforce displays Apex sharing reasons in the Reason column when viewing the sharing for a custom object record in the user interface. This allows users and administrators to understand the purpose of the sharing. When working with Apex sharing reasons, note the following:
Apex sharing reasons are only available for custom objects. Only users with the Modify All Data permission can add, edit, or delete sharing that uses an Apex sharing reason. Deleting an Apex sharing reason will delete all sharing on the object that uses the reason. You can create up to 10 Apex sharing reasons per custom object.
To create an Apex sharing reason: 1. 2. 3. 4. 5. Click Your Name | Setup | Create | Objects. Select the custom object. Click New in the Apex Sharing Reasons related list. Enter a label for the Apex sharing reason. The label displays in the Reason column when viewing the sharing for a record in the user interface. The label is also enabled for translation through theTranslation Workbench. Enter a name for the Apex sharing reason. The name is used when referencing the reason in the Force.com API and Apex. This name can contain only underscores and alphanumeric characters, and must be unique in your organization. It must begin with a letter, not include spaces, not end with an underscore, and not contain two consecutive underscores. 6. Click Save.
Defining Delegated Administrators


To delegate administration:
To be a delegated administrator:
Define delegated administration groups to specify groups of users who you want to have the same administrative privileges. These groups are not related to public groups used for sharing. 1. 2. 3. 4. Click Your Name | Setup | Security Controls | Delegated Administration. Click New. Enter a group name. Select Enable Group for Login Access if you want to allow delegated administrators in this group to log in as users who have granted login access to their administrators and are in the roles selected for the delegated administrator group. To find out how users can grant login access to their administrators, see Granting Login Access. 5. 6. 7. 8. 9. Click Save. Click Add in the Delegated Administrators related list to specify the users in this delegated group. Use the magnifying glass lookup icon to find and add users to the group. The users must have the View Setup and Configuration permission. Click Save. See Delegating User Administration and Delegating Custom Object Administration to specify what tasks these users can perform.
Delegating User Administration


Enable delegated administrators to manage users in specified roles and all subordinate roles, assign specified profiles to those users, and log in as users who have granted login access to administrators. 1. 2. 3. 4. 5. 6. 7. Click Your Name | Setup | Security Controls | Delegated Administration. Select the name of an existing delegated administration group. Click Add in the User Administration related list. Use the magnifying glass lookup icon to find and add roles. Delegated administrators can create and edit users in these roles and all subordinated roles. Click Save. Click Add in the Assignable Profiles related list. Use the magnifying glass lookup icon to find and add profiles. Delegated administrators can assign these profiles to the users they create and edit. Note that profiles with the Modify All Data permission cannot be assigned by delegated administrators.Note If a user is a member of more than one delegated administration group, be aware that he or she can assign any of the assignable profiles to any of the users in roles he or she can manage. 8. 9. Click Save. See Delegating Custom Object Administration to specify what custom objects the delegated administrators can manage.
To remove roles or profiles from the list of items the delegated administrators can use, click Remove next to the role or profile.
Delegating Administrative Duties


Use delegated administration to assign limited administrative privileges to selected non-administrator users in your organization. Delegated administrators can perform the following tasks:
Creating and editing users and resetting passwords for users in specified roles and all subordinate roles, including setting quotas, creating default sales teams, and creating personal groups for those users Assigning users to specified profiles Logging in as a user who has granted login access to their administrator
Managing custom objects created by an administrator
For example, you may want to allow the manager of the Customer Support team to create and edit users in the Support Manager role and all subordinate roles. This allows the administrator to focus on tasks other than managing users for every department that uses Salesforce. To create delegated groups, click Your Name | Setup | Security Controls | Delegated Administration, then click New. To manage your delegated groups:
Click Edit next to a group to modify it. Select a group and click Delete to remove it. Select a group and click Remove next to the user in the Delegated Administrators related list to remove a user from that delegated group.
Note To delegate administration of particular objects, use object permissions, such as View All and Modify All.
Delegating Custom Object Administration


Enable delegated administrators to manage custom objects that have been created by an administrator. 1. 2. 3. 4. 5. Click Your Name | Setup | Security Controls | Delegated Administration. Select the name of an existing delegated administration group. From the detail page of the delegated administration group, click Add in the Custom Object Administration related list. Use the magnifying glass lookup icon to find and add custom objects. Delegated administrators can customize nearly every aspect of a custom object, including creating a custom tab for it. Click Save. Click Save & More to add additional custom objects.
To remove a custom object from the list of items the delegated administrators can manage, click Remove next to the custom object.
Notes on Delegated Administration of Custom Objects

Delegated administrators can customize nearly every aspect of the custom object, including creating a custom tab for it. However, they cannot create or modify relationships on the object or set organization-wide sharing defaults. Delegated administrators need to have access to custom objects if they need to access the merge fields on those objects from formulas.

SFDC Notes

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SFDC Notes

Hochgeladen von

Copyright:

Verfügbare Formate

Dev401 Certification- Points to Remember

Study Guide for Certification Topics Covered in an Order

Prepared By Pramod Kumar. V

History Tracking Implementation Tips Administration

labels interface or the IDE for custom object translation.

Professional, Enterprise, Unlimited, and Developer Editions

User Permissions Needed

To add or edit languages:

To export or import translation files To translate terms:

Tags Overview Available in:

Enabling Tags Tag settings available in:

User Permissions Needed

To modify tag settings:

Use these tips when enabling tags.

Tagging Records Available in:

User Permissions Needed

To edit tags on a record:

Read on the record

Add Tags. If the record already has associated tags,

Removing Tags from Records Available in:

User Permissions Needed

To edit tags on a record:

Read on the record

User Permissions Needed

Tags Limits Available in:

You can have a maximum of:

Across all users, your organization can have a maximum of:

Notes: Object Permissions

Edit the custom profiles, enabling the permissions you want.Tip

change permissions for

multiple profiles from the list view.

queues to distribute ownership of custom object records to your

Deploying Custom Objects Available in:

Contact Manager, Group, Professional, Enterprise, Unlimited, and Developer Editions

User Permissions Needed

To deploy custom objects:

Contact Manager, Group, Professional, Enterprise, Unlimited, and Developer Editions

User Permissions Needed

To delete custom objects:

Notes on Deleting Custom Objects

Salesforce restores these items if you restore the custom object.

Custom Field Type .

You cannot delete a custom object if it is referenced in: o An Apex script

A Visualforce page An analytic snapshot

The developer name was changed to

objectname_del. Edit the object to change the developer name.

If the deleted custom object is on the detail side of a master-detail relationship:

About Default Field Values Available in:

Contact Manager, Group, Professional, Enterprise, Unlimited, and Developer Editions

Checkbox Currency Date

Developer, Enterprise, and Unlimited Editions

grant login access to another user, be aware that the

User Permissions Needed

Up to 1,000 entries Up to 255 characters per entry

Custom multi-select picklists can have:

Up to 150 values Up to 40 characters per value

Considerations for Relationships

Relationship Type Standard Report Types

Report Type Category

Primary master object by itself Secondary master object by itself

Primary master object and

Relationship Type Standard Report Types

Report Type Category