I expect that this will be a recap for you; however, just to be sure, I would like to summarize the functionalities paired with some of the most popular core CRM objects. This is important, as a lot of questions in the exam will give you business scenarios around these objects, and before thinking about programmatic solutions, you should consider whether there is any declarative solution that comes out of the box that could be used to meet the requirement.

The lead object is mostly used for individuals and/or companies that have been identified as potential customers but have not been qualified yet. Leads can be created in several ways; you can create them manually one by one, by clicking on New in the Lead tab. They are usually imported from .csv files (and quite possibly bought by your marketing and/or sales department). Alternatively, they can be created automatically when using the out-of-the-box web-to-lead functionality that generates the HTML form that you put on specific pages of your website(s).

Some of the functionalities that are offered by Salesforce for leads are as follows:

• Web-to-lead functionality: This generates an HTML form that you can use on any web page. Here, you select the lead fields you would like the user to fill in on your website and it automatically creates a lead in Salesforce on submission of the form. Be aware that validation rules and duplicate management rules configured on the lead object will also be applied. Web-to-lead functionality works well when combined with auto-response rules and assignment rules. It has a limit of 500 created leads within a 24 hour period. If this limit is reached, Salesforce stores the overflow in a queue and will treat them when the limit is refreshed. Be aware that this queue is limited to 50,000 leads and cases. It is possible to increase the daily limit by submitting a case at Salesforce Support.
• Lead auto-response rules: When new leads get created, you can specify whether an email needs to be sent to the lead automatically, and which email template should be sent out.
• Lead assignment rules: Upon lead creation, you could set up the automatic assignment of these leads to specific users or queues based on specific criteria, such as by language, segment, or sector. You can only have one active assignment rule per object, but this assignment rule can contain multiple criteria and logic entries.
• Lead queue: Custom objects and some standard objects (including leads) can be assigned to a queue. Queues are similar to lists of records, where these records are waiting to be picked up and treated by members assigned to the queue. Queue members can then pick records from the queue and go on to contact the lead, disqualify them, and then start the conversion process. A queue can contain public groups, roles, subordinates, and users as queue members.
• Lead conversion: Within a standard sales process, leads usually require some sort of disqualification. This means that someone will try to contact the lead and will try to determine whether they could potentially do business together. A common means of qualification is to determine the Budget, Authority, Need, and Time (BANT). If the lead does not qualify, then the status is changed to disqualified. If the lead does qualify, then the lead will be converted into an account, a contact, and, optionally, an opportunity. This conversion process will map lead fields to corresponding fields on the account, contact, and opportunity, which can be defined by a system administrator:

Accounts are orgs or individuals (when Person Accounts is enabled) that are involved with your business in some way (such as the customer, competitor, partner, or supplier).

There are two types of accounts, as follows:

• Business accounts (B2B): This is the default account type. An account usually contains the general information about a company, such as the name, billing address, shipping address, sector, segment, and VAT number. They also contain several related lists of records, such as the people who work there, the cases that are logged, the opportunities that are sent, the documents that are uploaded, and more.
• Person accounts (B2C): If your company also deals with individuals, not companies, you can ask Salesforce to enable Person Accounts in your org. However, be aware that once this feature has been enabled, it cannot be disabled (but you can still choose not to use the record type). Person Accounts are a combination of the account object and the contact object. They mostly contain user information, such as first name, last name, date of birth, gender, hobbies, interests, and more.

Of course, if your company deals in both B2B and B2C, then you can use both business accounts and Person Accounts in your org.

The account object also comes with some specific features, as follows:

• Account hierarchies: The account object has a standard lookup field called the parent account. When this is filled in, it creates a hierarchical relationship between the accounts. When clicking on View Account Hierarchy from an account, you can see the whole account relationship from the point of view of the current record. You can easily navigate from one account to the other within the hierarchy. An admin can also modify or adjust up to 15 columns, shown on the Hierarchy overview page, through Setup | Object Manager | Account | Hierarchy Columns. The following screenshot shows how Account Hierarchy is presented to the user on the Salesforce interface:

The Account Hierarchy is most commonly used in the following way:

• Account teams: These are another way in which to grant access to a specific account record, next to Organisation-Wide Defaults (OWD), sharing rules, and manual sharing. Here, the owner of an account can specify other users (called Account Team Members) working on that same account with a specific business role (such as inside sales, support representatives, and project managers) and specific privileges (read-only or read-write). The user is also able to specify a default account team for each user, which will automatically be added onto the account where that user is the owner of the account. The account teams feature is disabled by default; you can enable it by going to Setup | Feature Settings | Sales | Account Teams.

This refers to the individuals working on your accounts with whom you have contact. It mostly contains more personal details such as date of birth, gender, and language. Additionally, it can also contain company details, such as title, department, and, optionally, their relationship to another contact to whom they report. This ReportsToId lookup field is similar to the Parent Account field, and allows you to present a hierarchy between your contacts.

Under normal circumstances, a contact is always directly related to an account. It is possible to mark the account lookup as non-required, but when a contact is not associated with an account, then it becomes a private contact instead. Private contacts are only visible to the record owner and system administrators, and cannot be shared with others.

For marketing purposes, it is important to avoid duplicates between contacts; however, what if the same contact plays a role on multiple accounts?

For this specific reason, Salesforce introduced a new feature called Contacts to Multiple Accounts. This feature is disabled by default, but you can enable it through Setup | Feature Settings | Sales | Account Settings:

Once enabled, the related list, related account, and related contact details will need to be added to your respective contact's and account's page layouts. You can remove the standard contact's related list from the account page layout because the new related list contains both the direct and indirect contacts or accounts.

Each contact will still have one direct account through account lookup, but you will be able to create extra relationships with other accounts by adding a new Account Contact Relationship. These will automatically be marked as indirect. However, because these relationships are with another specific object in the Salesforce database, the individual will only exist once in the contact table, which is fantastic news for your marketing department.

This represents the potential revenue that sales representatives can track through different stages of the sales process until the deal is either won or lost. Opportunities come with multiple sales-related features, as follows:

• Building your company's pipeline
• Forecasting the revenue and determining the next steps to move forward in the sales cycle

In combination with products, price books, and price book entries (prices), opportunities can add a great level of detail to what you are selling to your customers.

The opportunity object comes with some specific features, as follows:

• Opportunity teams: This is very similar to account teams; they allow you to add other users to work on the same opportunity with a specific role and access right. In the user record list, it's also possible to add a default opportunity team.
• Opportunity splits: If opportunity teams are enabled, then you also enable opportunity splits. These are used to share the revenue of an opportunity between multiple users. In this way, they all contribute to win the deal. This means that the opportunity team members, who are collaborating to win an opportunity, will individually get credit in the pipeline reports, and this will contribute to them achieving their quota. Note that this is not really something that you must know for the exam, so if you want to learn more about this topic, then you can read more at https://help.salesforce.com/articleView?id=teamselling_opp_splits_overview.htm&type=5.
• Collaborative forecasting: This feature will help you predict the pipeline. A forecast represents the expected revenue based on the sum of the total set of opportunities. They can be adjusted by managers in order to get a more accurate forecast without effectively changing the underlying opportunity's amounts. They are split up by the forecast category, time period, and, optionally, by product.