Only $35.99/year

Salesforce Admin 201 practice review

Terms in this set (96)

~Defining Assignment Rules~
When incoming leads are imported or generated through your web-site, Salesforce automatically assigns them to users in the queues

-Creating Lead Queues: lead queue is a place to store unassigned leads

-Selecting a default lead owner: Default lead owner becomes the owner of a lead when no assignment rules apply. This can be a person or a queue. Select a default lead owner so that no lead can fall through the cracks.

-Creating Lead Assignment Rule when Creating or Editing a Lead: Your administrator can create a lead assignment rule to automatically assign leads to different users or queues based on lead criteria. For example, a rule entry can assign leads from people in western states to your west coast sales rep.

-Web-to-Lead: Contact information from your web-site redirects the information into Salesforce automatically generating a lead (required HTML on product page). Additionally an email can automatically be sent to the default lead creator who can then re-assign. A response default email template can also be sent to leads when they submit an online lead.

Importing Leads: Importing your lead data into Salesforce is easy as long as it is in CSV format. When importing new leads, your administrator can apply a lead assignment rule to automatically assign leads to users or queues based on values in certain lead fields. Alternatively, your administrator can add a Record Owner field to the import file to assign lead ownership. Without a lead assignment rule or Record Owner field, imported leads are automatically assigned to the user doing the import.
Overview of Relationships:
Use relationships to associate an object with other objects in Salesforce. (Custom fields and relationships) You can define different types of relationships by creating custom relationship fields on an object.
There are different types of relationships between objects in Salesforce. Their differences include how they handle data deletion, sharing, and required fields in page layouts.
~Master-detail Relationship~
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 Account—Expense Report, that extends the relationship to subdetail records, such as Account—ExpenseReport—Expense Line Item. You can then perform operations across the master—detail—subdetail relationship.
Behaviors of master-detail relationships include:
-When a master record is deleted, the related detail and subdetail records are also deleted.
-By default, records can't be reparented in master-detail relationships. Administrators can, however, allow child records in master-detail relationships on custom objects to be reparented to different parent records by selecting the Allow reparenting option in the master-detail relationship definition.
-The owner of the master record own the detail and subdetail records. Custom objects on the "detail" side of a master-detail relationship can't 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.
-As a best practice, don't exceed 10,000 child records for a master-detail relationship.
-In a many-to-many relationship, a user can't delete a parent record if more than 200 junction object records are associated with it and if the junction object has a roll-up summary field that rolls up to the other parent
-Custom object: Maximum Number of Master - Detail Relationships = 23
-A master detail relationship on an object can only be created before the object contains record data
~Lookup Relationship~
This type of relationship links two objects together but has no effect on deletion, record ownership or security.
~Hierarchical Relationship~
A self or hierarchical relationship exists when there is a lookup on a field object that points back to the same object that lookup field is on
~Many to Many/Junction~
A many-to-many relationship allows each record of one object to be linked to multiple records from another object and vice versa. Use a junction object to connect the two objects you want to relate to each other.
A Junction object is a custom object with two master detail relationships with a sole purpose of simply relating two objects.
System Admin: (super user) Has access to all functionality that does not require an additional license. For example, administrators cannot manage campaigns unless they also have a Marketing User license.

Standard user: Can use custom apps and the apps from Appexchange + can use core platform functionality such as accounts, contacts, reports, dashboards, and custom tabs

Solution manager: Standard User + Can review and publish solutions.

Marketing user: Standard User+Can manage campaigns, import leads, create letterheads, create HTML email templates, manage public documents, and update campaign history via the import wizards.
.
Partner user: Can only log in via a partner portal.

Customer portal user/manager: Can only log in via a Customer Portal. Can view and edit data they directly own or data owned by or shared with users below them in the Customer Portal role hierarchy; and they can view and edit cases where they are listed in the Contact Name field.
Contract manager: Can create, edit, activate, and approve contracts. This profile can also delete contracts as long as they are not activated. Can edit personal quota and override forecasts.

Read only: (executive team) Can view the organization's setup, run and export reports, and view, but not edit, other records.

Chatter user/moderator: Can only log in to Chatter. Can access all standard Chatter people, profiles, groups, and files.

Site.com user: Can only log in to the Site.com app. Each Site.com Only user also needs a Site.com Publisher feature license to create and publish sites, or a Site.com Contributor feature license to edit the site's content
-Force.com Managed Sharing
Force.com managed sharing involves sharing access granted by Force.com based on record ownership, the role hierarchy, and sharing rules.

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

-Role Hierarchy
The role hierarchy enables users above another user in the hierarchy to have the same level of access to records owned by or shared with users below. Consequently, users above a record owner in the role hierarchy are also implicitly granted Full Access to the record, though this behavior can be disabled for specific custom objects. The role hierarchy is not maintained with sharing records. Instead, role hierarchy access is derived at runtime.

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

-User Managed Sharing, also known as Manual Sharing
User managed sharing allows the record owner or any user with Full Access to a record to share the record with a user or group of users. This is generally done by an end-user, for a single record. Only the record owner and users above the owner in the role hierarchy are granted Full Access to the record. It is not possible to grant other users Full Access.

-Apex Managed Sharing
Apex managed sharing provides developers with the ability to support an application's particular sharing requirements programmatically through Apex or the SOAP API.
SHARING RULES open up access to automatically grant users access to objects when OWD or Role hierarchy doesn't allow it. (Sharing rules works best if used on a predicted group of users {Roles}.

-Sharing rules allow you to selectively grant data access to defined sets of users.

-You can use sharing rules to grant wider access to data.

-When you transfer records from one user to another, the sharing rules are reevaluated to add or remove access to the transferred records as necessary.

-When you modify which users are in a group, role, or territory, the sharing rules are reevaluated to add or remove access as necessary.

-Sharing rules automatically grant additional access to related records. For example, opportunity sharing rules give role or group members access to the account associated with the shared opportunity if they do not already have it.

-If multiple sharing rules give a user different levels of access to a record, the user gets the most permissive access level.

-Users in the role hierarchy are automatically granted the same access that users below them in the hierarchy have from a sharing rule, provided that the object is a standard object or the Grant Access Using Hierarchies option is selected.

-Regardless of sharing rules, 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.

-Making changes to sharing rules may require changing a large number of records at once. To process these changes efficiently, your request may be queued and you may receive an email notification when the process has completed.

-You can create rules to share records between most types of Customer Portal users and Salesforce users as they have the Customer Portal Manager user license. However, you can't include high-volume portal users in sharing rules because they don't have roles and can't be in public groups.

-Lead sharing rules do not automatically grant access to lead information after leads are converted into account, contact, and opportunity records.

-In a master detail object relationship, you cannot create a sharing rule for a detail object, it is inherited.
-Tabular reports are the simplest and fastest way to look at data. Similar to a spreadsheet, they consist simply of an ordered set of fields in columns, with each matching record listed in a row. Tabular reports are best for creating lists of records or a list with a single grand total. They CAN NOT be used to create groups of data or charts, and can't be used in dashboards unless rows are limited. Examples include contact mailing lists and activity reports.

- Summary reports are similar to tabular reports, but also allow users to group rows of data, view subtotals, and create charts. They can be used as the source report for dashboard components. Use this type for a report to show subtotals based on the value of a particular field or when you want to create a hierarchical list, such as all opportunities for your team, subtotaled by Stage and Owner. Summary reports with no groupings show as tabular reports on the report run page.

- Matrix reports are similar to summary reports but allow you to group and summarize data by both rows and columns. They can be used as the source report for dashboard components. Use this type for comparing related totals, especially if you have large amounts of data to summarize and you need to compare values in several different fields, or you want to look at data by date and by product, person, or geography. Matrix reports without at least one row and one column grouping show as summary reports on the report run page.

-Joined reports let you create multiple report blocks that provide different views of your data. Each block acts like a "sub-report," with its own fields, columns, sorting, and filtering. A joined report can even contain data from different report types.