Part 1 - Apex & .

NET Basics {Basics, goes over things}

https://trailhead.salesforce.com/content/learn/modules/apex_basics_dotnet?trailmix_creator_id=st
railhead&trailmix_slug=prepare-for-your-salesforce-platform-developer-i-credential

Lesson 1 - Map .NET Concepts to the Lightning Platform

In this module, we’ll look at how you can relate the .NET concepts that you’re already familiar
with to the Lightning Platform.

Platform Basics

One of the things that separates the platform from other software-as-a-service
(SaaS) offerings is that it relies on a metadata-driven architecture. Everything,
including the code, configuration, and apps, is specified as metadata.

As .NET developers, you’re probably already familiar with the cloud applications that
run on Microsoft Azure. Well, the Lightning Platform works differently. The Lightning
Platform is tightly integrated with the database. You also get all sorts of things, like
user interface, security, and reporting, built right in with the platform. This integration
is what lets you build apps super fast.

BUT - On the Lightning Platform, we don’t have to worry about setting up nodes or
management tasks. You don’t have to worry about upgrading, tuning, or scaling anything. To
be honest, you probably won’t miss all that added complexity and responsibility, because
instead you can just focus on quickly building great apps.

Apex Basics
Because the Lightning Platform is so tightly integrated and relies on a metadata architecture,
you can accomplish an awful lot using declarative development, or what is known as “point-
and-click” app building.

As a .NET developer, on the Lightning Platform, code is not always needed. But it’s important
to understand when code is needed and when it isn’t. You can learn more about this
distinction by browsing this article on when to click and when to write code.

What Is Similar?
The Apex programming language is similar to C#. Apex is saved, compiled, and executed
directly on the Lightning Platform. Like C#, it’s object oriented. In this section, we’ll go
over this and what else makes it similar to .NET languages.
Object-oriented Design
Apex supports many of the object-oriented principles that you’re probably used to, such as
encapsulation, abstraction, inheritance, and even polymorphism. In fact, the Apex language
includes many language constructs you’re already familiar with, including classes, interfaces,
properties, and collections.

For example, here is what an Apex class named HelloWorld would look like.

This simple HelloWorld class includes one method named printMessage that is used to
simply output the message “Hello World” to the system debug log.

The basic syntax for defining classes is: - + A link to Understand Classes

Check out Understanding Classes to learn more about how classes, objects, and interfaces
work.

https://developer.salesforce.com/docs/atlas.en-
us.apexcode.meta/apexcode/apex_classes_understanding.htm?_ga=2.2105456.1326458405.1
712477921-919194799.1675078093

Data Types in Apex

• There are primitive types, such as Integer, Double, Long, Date, Datetime, String, and
Boolean
• There is also an ID data type that is used for any valid 18-character Lightning
Platform record identifier assigned by the system.
• Value and reference types work the same, but in Apex, all variables are initialized to null by
default. One thing to be aware of is that .NET strings are actually references even though
they behave like value types, because they’re immutable. But in Apex, strings are always
treated as a primitive value type.
• Besides primitives, supported data types include sObjects, either as a generic sObject or a
specific one, such as an Account or Contact. Remember, an sObject is just a Salesforce
 object. You can think of it as a table in a database. The sObject can be either a standard one
or a custom one that you define yourself.

Enum – Data Type

Additionally, a data type can be a typed list of values, also known as an enum. But watch out,
because these aren’t the same enums you’re used to working with in .NET. In Apex, you can use
enums with numbers, but you can’t define what these number values are. Also, the ordinal
assignment starts at zero. For example, if you had an enum like the following.

Working with Collections – Lists, Sets, Maps

List – Declaring a List

A list is an ordered collection of elements that works much the same as a traditional array. In
fact, arrays in Apex are synonymous with lists, and you can use them interchangeably.

You can also add values to the list after it has been created, Like so:
You’ll probably create a lot of list variables in your Apex development, because the output of
every SOQL query is a list. For example, you could create a list of Accounts using code such
as the following:

Like arrays, lists have indexes that start at zero. So you could access the name of the first
account in the list with code like this:

Set
A set is an unordered collection of elements that does not contain duplicates. A set is
commonly used to store ID values because the value are always unique.

You could then use the set as part of a WHERE clause in a SOQL query.

For example, here we’re creating a set that contains two unique IDs for Accounts. We then
use the set in the SOQL query to return Accounts only for those IDs.

Map
A map is a collection of key-value pairs. Each key maps to a single value.

A map is useful when you need to quickly find something by a key. The key values must be
unique, so you could have a map that contained ID values for the key and then mapped to
an sObject.

For example, you could use the following code to declare a map variable named accountMap
that contains all Accounts mapped to their IDs.

You could then access a specific Account record using the get method and code
similar to the following.

Check out the official docs to learn more about the data types that Apex supports.
ASP.NET to Visualforce

There are many similarities between the two., most notably, a clear separation of the
markup from the code. You also use form fields to map code to properties defined in
the controller.

The bad news is that viewstate is just as much a pain with Visualforce as it is with
ASP.NET due to the fact that HTTP is stateless ☹.

The good news is that there are ways around the viewstate limitations. 😊 (Learn
more by checking out the link in Resources.)

Visualforce is a framework for rendering HTML pages using an MVC paradigm. You
can use either one to render web pages, and both separate the application logic
from the markup and the database model, but they do so in different ways.

To learn all about Visualforce, check out the Visualforce Basics module (Later on in
this trailmix). For now, we just want to give you a basic idea of how it works by
showing you an example. You can use the following markup code to render a
simple page used to enter Contact data.

This example uses what is known as a standard controller, which is part of the Lightning
Platform. It’s basically system-generated code that allows you to quickly incorporate
basic CRUD functionality in your Visualforce pages. Before you start getting worried, just
know that you can create your own custom controllers to add in more complex functioning.
Learn all about how standard and custom controllers work in the Visualforce Basics module.
The rendered version of this page looks like the following:

*Lightning is a lighter weight way of delivering super fast and responsive web apps, but
Lightning is a component-based framework. (More in future module here in the Trailmix)

What Is Different?
• For starters, unlike C#, Apex is not case sensitive.
• Apex and Database are Tightly Coupled

Apex code and the Lightning Platform database are tightly coupled to the point where they
are sometimes indistinguishable. Each standard or custom object in the database has a
"mystical" representation via an Apex class that provides all sorts of functionality to make
interacting with the database a snap.

The class and its underlying object are essentially a mirror image of one another that is
constantly in sync. For instance, whenever you create a new field in an object, a class
member is automatically surfaced to reference the values in the database. It's also impossible
to add a reference in your Apex code to a field that doesn't exist; the compiler will return an
error and simply not save your code. The platform works hard to ensure these dependencies
and won't let the database schema and your code become out of sync. Therefore, if you
attempt to delete a custom object or a field that is referenced by Apex code, the platform
will raise an error and disallow the action.

• Different Design Patterns

In Apex – if you try to apply the same design strategies that you use in .NET to the Lightning Platform,
you’ll likely encounter problems when you go to test and deploy your solutions. We suggest taking
some time to learn about which design patterns work best in the Lightning Platform world before
you start cranking out the code.

• Unit Tests Are Required

On the Lightning Platform you must have 75% test coverage to deploy your Apex code
to a production org. Not only does having unit tests promote the development of robust
and error-free code, but they’re vital to the stability of the platform, because all tests are
run before every major release. To learn more about unit testing, see An Introduction to
Apex Code Test Methods.

• No Solution, Project, or Config Files

The Lightning Platform has no such thing as a solution or project file. You can create an application,
but it’s not the same as creating a .NET application or assembly.
An application on the Lightning Platform is just a loose collection of components, such as tabs,
reports, dashboards, and pages. Several come built in with your Salesforce org, and in a few
seconds, you can create your own by walking through a point-and-click wizard. You can even
purchase apps created by third-parties on what is known as the AppExchange.

All your code resides and executes in the cloud. There is also no such thing as a config file in the
Lightning Platform world. And unlike ASP.NET MVC, you don’t need to configure routes. You can
create custom settings in Salesforce, but these are added and managed declaratively.

• A Much Smaller Class Library

The Apex class library is considerably smaller than the .NET Framework class library, so it’s easier and
faster for you to come up to speed with Apex.

Keep in mind that the Lightning Platform is built with the idea of providing rapid application
development.

However, if you’re looking to build pixel-perfect, custom-coded applications, our Heroku Enterprise
platform provides all the power and features you need.

• Development Tools\ Developer Console - to edit and navigate source code, and it’s also
helpful for debugging and troubleshooting.
• Salesforce CLI (Not in Trailmix\CRM Period PDF)

https://developer.salesforce.com/tools/salesforcecli

The Salesforce CLI is a powerful command line interface that simplifies development and build
automation when working with your Salesforce org. Use it to:

• Aggregate all the tools you need to develop with and perform commands against your
Salesforce org
• Synchronize source to and from scratch orgs
• Create and manage orgs
• Import and export data
• Create and execute tests
• Create and install packages

Handling Security
Identity is handled by the platform. You can control access to data at many different levels,
including object level, record level, and field level. Security is also handled declaratively. In
many cases, security is defined and set up by a Salesforce administrator. As a developer, it’s
important to be aware of how it works. Learn more by checking out the Data
Security module.

Integration

You can integrate with the platform in a number of ways, but you’ll probably use
SOAP and REST the most. You can use them in either direction.
You can create and expose web services using the Apex programming language, as
well as invoke external web services from Apex.
You can also react to incoming email messages and have automated outbound
messages sent when certain events occur.
Salesforce offers both SOAP and REST APIs that provide direct access to the data in
your org. Toolkits that wrap around the APIs are available, so you can use whatever
language you prefer: .NET, Java, PHP, Objective C, Ruby, and JavaScript.
Numerous third-party integration applications are also available on the
AppExchange. Really, just about anything is possible. You can learn more about all
the integration points by completing the Apex Integration module.

Create an Apex Class

The class we’ll create includes the public method sendMail. It includes a private helper
method called inspectResults for inspecting the results of the email send call.

1. From Setup in your Developer org, select Your Name > Developer
Console to open Developer Console.
2. In Developer Console, select File > New > Apex Class.
3. Enter EmailManager as the class name and click OK.
4. Delete the existing code, and insert the following snippet: (And save the class)
Invoke a Method

Because we declared the public sendMail method as static, we can access it without
creating an instance of the class. We can do so easily by using Anonymous Apex in
Developer Console.

1. From Setup, select Your Name > Developer Console to open Developer
Console.
2. Select Debug > Open Execute Anonymous Window.
3. Delete the existing code, and insert the following snippet:

EmailManager.sendMail('Your email address', 'Trailhead Tutorial', '123

body');

4. Make sure that the Open Log option is selected, and click Execute. A new tab
shows you the execution log.
5. Select the Debug Only option so that you see only the debug statements
displayed in the log. You should see a message telling you that the Email was
sent successfully. You should also receive an email if you entered a valid email
address.

EXAMPLE – Hands On Challenge - Create an Apex class that returns accounts

Create an Apex class that returns a List of Account objects for a user-specified state.

• Create an Apex class that contains a static method:

• Name: AccountUtils
• Method name: accountsByState
• The method must return the ID and name of all Account objects that
match the BillingState for the state abbreviation passed to the method

Answer:

Lesson 2 - Understand Execution Context

What Is Execution Context?

In the Lightning Platform world, code executes within an execution context. In a

nutshell, this context represents the time between when the code is executed and
when it ends. The important thing for you to understand is that the Apex code you
write is not always the only code that is executing.

To understand how this works, you need to know all the ways Apex code can be
executed on the platform.

Methods of Invoking Apex

Method Description
Database Trigger Invoked for a specific event on a custom or standard object.
Anonymous Apex Code snippets executed on the fly in Dev Console & other tools.
Asynchronous Occurs when executing a future or queueable Apex, running a batch job, or
Apex scheduling Apex to run at a specified interval.
Web Services Code that is exposed via SOAP or REST web services.
Email Services Code that is set up to process inbound email.
Visualforce or Visualforce controllers and Lightning components can execute Apex code
Lightning Pages automatically or when a user initiates an action, such as clicking a button.
Lightning components can also be executed by Lightning processes and flows.

Besides invoking Apex code, actions, such as creating a new task, sending an email,
performing a field update, or sending an outbound message, can all be triggered by one of
the declarative platform features. These actions also run within an execution context.

• Another important consideration is the context of the user executing the Apex code.
By default, Apex executes in system context. Apex code has access to all objects and
fields. Object permissions, field-level security, and sharing rules aren’t applied for the
current user. You can use the with sharing keyword to specify that the sharing rules
for the current user be taken into account for a class. This topic is important, so check
out Using the with sharing or without sharing keywords.

Trigger Essentials

Similar to triggers in SQL Server, Apex database triggers execute programming logic
before or after events to records in Salesforce. When defining the trigger, you can
specify more than one of the following events:

• before insert
• before update
• before delete
• after insert
 • after update
• after delete
• after undelete

The basic syntax for a trigger looks like the following:

You only want to resort to using a trigger when you are absolutely sure that the same
thing cannot be accomplished with one of our point-and-click automation tools.
(Flows)

Mark Execution Context

Let’s walk through creating an Apex database trigger that creates an opportunity
when a new account is entered. This trigger calls a method from a handler class, so
we first need to create that.

1. From Setup, select Your Name > Developer Console to open Developer
Console.
2. In Developer Console, select File > New > Apex Class.
3. Enter AccountHandler for the class name and click OK.
4. Delete the existing code, and insert the following snippet: And save the class.

It’s considered a best practice to use only one trigger per object.

So now that we have the handler class, we create the Account trigger.
 1. In Developer Console, select File > New > Apex Trigger.
2. Enter AccountTrigger as the name, and select Account as the sObject.
3. Click Submit.
4. Delete the existing code, and insert the following snippet: And save the
Trigger

To complete the walkthrough, we execute anonymous code to simulate a user

entering a new Account using the Salesforce interface. Remember, Apex code can be
executed a number of different ways.

1. From Setup, select Your Name > Developer Console to open Developer
Console.
2. Select Debug > Open Execute Anonymous Window.
3. Delete the existing code, and insert the following snippet

4. Make sure that the Open Log option is selected and click Execute. A new tab
shows the execution log. Keep it open so that you can examine it carefully.

The Execution Log

Notice that the first line in the execution log marks the EXECUTION_STARTED event
and that the last line is the EXECUTION_FINISHED event. Everything in between is the
execution context.

Let’s take a closer look at what happens. A CODE_UNIT_STARTED event marks when
the code from the Execute Anonymous window was kicked off. This line is
highlighted in red in the image below.
The second CODE_UNIT_STARTED line that is highlighted represents when code for
the BeforeInsert event was executed.

You can’t see this in the image, but if you’re following along with your own instance
of Developer Console, scroll down further in the results and look for other instances
of CODE_UNIT_STARTED. You should see at least one more instance representing
when code for the AfterInsert event was executed. If you had created workflow rules
that fired when a new account was created, they too would show up in the execution
log. All this code operates under the same execution context, and thus, is subject to
the same set of governor limits.

Working with Limits (Explained later)

Working in Bulk(Explained later)
Apex triggers can receive up to 200 records at once. Currently, the synchronous limit for the
total number of SOQL queries is 100, and 150 for the total number of DML statements issued
So, if you have a trigger that performs a SOQL query or DML statement inside of a loop and
that trigger was fired for a bulk operation - you’re going to get a limits error!
 • There is no such thing as an application or session variable in the
Lightning Platform. If you need data to persist between classes, you do have
static variables, but keep in mind that static variables in the Lightning Platform
don’t work the same as they do in .NET. In the Lightning Platform world, a
static variable can only persist information within a single execution context,
although other options for maintaining data across trigger invocations are
available. Check out the Advanced Apex links in Internet Resources to learn
more.
• When working with Limits, there are many tradeoffs to consider, especially for
developers of managed packages. By the way, Salesforce partners typically use
managed packages to distribute and sell applications. In this module, we just
skimmed the surface of what you need to know. If you’re serious about Apex
development, check out the Advanced Apex links in Internet Resources.

<Stopped copying and pasting due to more modules later >

Lesson 3 – Use Asynchronous Apex

When to Go Asynchronous

• Processing a very large number of records. This reason is unique to the

multi-tenanted world of the Lightning Platform where limits rule. The limits
associated with asynchronous processes are higher than those with
synchronous processes. Therefore, if you need to process thousands or even
millions of records, asynchronous processing is your best bet.
• Making callouts to external web services. Callouts can take a long time to
process, but in the Lightning Platform, triggers can’t make callouts directly.
• Creating a better and faster user experience by offloading some processing
to asynchronous calls. Why do everything at once? If it can wait, let it.

Future Methods @Future

When you need to make a callout to a web service or want to offload simple
processing to an asynchronous task, creating a future method could be the way to
go.

Changing a method from synchronous to asynchronous processing is amazingly

easy. Essentially, you just add the @future annotation to your method. Other than
that, just make sure that the method is static and returns only a void type.
For example, to create a method for performing a web service callout, we could do
something like this:

@Future Limitations

• You can’t track execution because no Apex job ID is returned.

• Parameters must be primitive data types, arrays of primitive data types, or
collections of primitive data types. Future methods can’t take objects as
arguments.
• You can’t chain future methods and have one call another.

Although asynchronous calls are sometimes done to avoid limits, you still need to
consider limits. Check out the link concerning Execution Governors and Limits in
Resources.

Batch or Scheduled Apex

Another long-used asynchronous tool is the batchable interface. The No. 1 reason to
use it is if you need to process a large number of records. For example, if you want to
clean up or archive up to 50 million records, the batchable interface is your answer.
You can even schedule your batches to run at a particular time.

To use it, your class implements the Database.Batchable interface. You also define
start(), execute(), and finish() methods. You can then invoke a batch class using the
Database.executeBatch method. For example, the following code creates a batchable
class that processes all accounts in an org and then sends an email when it is done.

You could then invoke the batch class using anonymous code such as this:

Batchable Limitations

The batchable interface is great, but as with just about everything, consider its
limitations.

• Troubleshooting can be troublesome.

• Jobs are queued and subject to server availability, which can sometimes take
longer than anticipated.
• Have we talked about limits yet?

Queueable Apex
Remember all those limitations we talked about? Well, they were causing problems for some
developers, so there was an outcry for a better solution.

Queueable Apex! It provides the following benefits to future methods.

 • Non-primitive types - Classes can accept parameter variables of non-
primitive data types, such as sObjects or custom Apex types.
• Monitoring - When you submit your job, a jobId is returned that you can use
to identify the job and monitor its progress.
• Chaining jobs - You can chain one job to another job by starting a second job
from a running job. Chaining jobs is useful for sequential processing.

Queueable Apex is much easier to implement than Batch Apex. It just doesn’t have those
pesky limitations we talked about. To demonstrate how it works, let’s take the sample code
that used a future method to do a web callout and implement it using Queueable Apex.

Lesson 4 - Debug and Run Diagnostics

https://trailhead.salesforce.com/content/learn/modules/apex_basics_dotnet/debugging_diagno
stics?trailmix_creator_id=strailhead&trailmix_slug=prepare-for-your-salesforce-platform-
developer-i-credential
The Debug Log

You can also specify one of the following logging levels.

• NONE
• ERROR
• WARN
• INFO
• DEBUG
• FINE
• FINER
• FINEST

These levels run from lowest to highest and are cumulative (They Stack‫) מצטבר‬. So if
you pick the finest level, you get all messages that are logged as error, warn, info,
and so on. There are also several debug log categories, and the amount of
information logged depends on the log level.

Ok, You’ve heard a lot about limits, but understanding limits are critical to your
success! Each debug log must be 20 MB or smaller. If it exceeds this amount, you
won’t see everything you need. Additionally, each org can retain up to 1,000 MB\1GB
of debug logs. The oldest logs are overwritten.

Because debug logs are your primary way of getting debug information about your
application, you want to make sure to not exceed these limits. If you never see an
error message, you can’t possibly do anything to address it. In the future you’ll learn
about Advanced Apex Debugging and Best Practices for tips on how to avoid these
kinds of issues.

Use the Log Inspector

Developer Console has grown quite a bit in the past few releases. One of its more
useful features is the Log Inspector. To see how it works, let’s walk through running
some anonymous code and viewing the results.

1. From Setup, select Your Name > Developer Console to open Developer
Console.
2. Select Debug > Change Log Levels.
3. Click the Add/Change link in General Trace Setting for You.
4. Select INFO as the debug level for all columns.
 5. Click Done.
6. Click Done.
7. Select Debug > Perspective Manager.
8. Select All (Predefined) and click Set Default.
9. Click Yes to change this to your default perspective.
10. Close the Developer Console Perspective window.
11. Select Debug > Open Execute Anonymous Window.
12. Delete the existing code, and insert the following snippet:

13. Make sure that Open Log is selected, and click Execute.
14. Select Debug > Switch Perspective > All (Predefined).
15. Examine the results in the Timeline and Executed Units tabs.
16. Under Execution Log, select the Filter option, and enter FINE. Because we set
the debug level to INFO for Apex Code, no results appear.
17. Select Debug > Change Log Levels.
18. Click the Add/Change link in General Trace Setting for You.
19. Change the DebugLevel for ApexCode and Profiling to FINEST.
20. Click Done.
21. Click Done.
22. Select Debug > Open Execute Anonymous Window.
23. Leave the code that is currently there, and click Execute.
24. Under Execution Log, select the Filter option, and enter FINE. The filter search
is case sensitive. You now see "My Fine Debug Message" displayed. You
should also notice a size difference between the two latest logs in the Logs
tab.

Set Checkpoints

Checkpoints are similar to breakpoints in that they reveal a lot of detailed execution
information about a line of code. They just don’t stop execution on that line.

To see how they work, let’s walk through setting a checkpoint on a line of code that
you created in an earlier unit on Understanding Execution Context. If you haven’t
created the handler and trigger code for the AccountTrigger, go back to that unit
and complete that section before continuing.

1. From Setup, select Your Name > Developer Console to open Developer
Console.
2. Select File > Open.
3. Select Classes as the entity type, and AccountHandler as the entity.
4. Click Open.
5. Position your cursor over line 10 in the left margin and click once. A red dot
appears next to the line number.
6. Double-click the latest entry in the Logs panel to open the debug log.
7. Select Debug > Open Execute Anonymous Window.
8. Delete the existing code, and insert the following snippet

9. Make sure that Open Log is selected, and click Execute.

10. Click the Checkpoints tab, and double-click the first entry that appears. The
Checkpoint Inspector appears.
11. On the Symbols tab, expand the nodes within the execution tree. Notice the
Key and Value columns.
12. Click the Heap tab. Notice the Count and Total Size columns.

Part 2 - Formulas and Validations

https://trailhead.salesforce.com/content/learn/modules/point_click_business_logic?trailmix_creator
_id=strailhead&trailmix_slug=prepare-for-your-salesforce-platform-developer-i-credential

Lesson 1 - Use Formula Fields

Find the Formula Editor

1. From Setup, open the Object Manager and click the required Object.
2. In the left sidebar, click Fields & Relationships.
3. Click New.
4. Select Formula

• When writing formulas, keep in mind that:

• Whitespace doesn’t matter. You can insert as many spaces and line
breaks as you want without affecting the formula’s execution.
• Formulas are case sensitive. Pay attention to capitalization of field and
object names.
• When working with numbers, the standard order of operations applies.

Further Examples

Let’s look at a few more examples. You can create these formulas yourself or simply
read through.

1. This formula creates a hyperlink to an external website using the HYPERLINK()

function. Adding hyperlinks to page layouts helps your users access important
information quickly from the detail pages.

2. If you want to apply a discount to an opportunity amount, you can use the
following formula. In this case, we’re applying a 12% discount and then
rounding the result to two decimal places using the ROUND() function.

3. This formula is a checkbox formula that determines whether a particular

opportunity is a “big” opportunity. It checks whether the number of
employees at the opportunity account’s associated company is greater than
1,000 AND whether the opportunity amount is greater than $10,000. If both
statements are true, the field appears as a checked box on the Opportunity
 page layout. Otherwise, it appears as a blank box.

The formulas documentation contains numerous examples for many different use
cases. While you’re browsing these examples, keep in mind that many of them
contain advanced concepts that weren’t covered in this unit. Make sure you’re
comfortable with the information presented here before tackling these formulas.

• Salesforce Help: Calculate Field Values With Formulas

• PDF: Formulas Quick Reference

Lesson 2 - Implement Roll-Up Summary Fields

While formula fields calculate values using fields within a single record, roll-up
summary fields calculate values from a set of related records, such as those in a
related list. You can create roll-up summary fields that automatically display a value
on a master record based on the values of records in a detail record. These detail
records must be directly related to the master through a master-detail relationship.

You can perform different types of calculations with roll-up summary fields. You can
count the number of detail records related to a master record, or calculate the sum,
minimum value, or maximum value of a field in the detail records. For example, you
might want:

• A custom account field that calculates the total of all related pending
opportunities.
• A custom order field that sums the unit prices of products that contain a
description you specify.
• There are a few different types of summaries you can use.

Type Description
COUNT Totals the number of related records.
SUM Totals the values in the field you select in the Field to Aggregate option. Only number,
currency, and percent fields are available.
MIN Displays the lowest value of the field you select in the Field to Aggregate option for all
directly related records. Only number, currency, percent, date, and date/time fields are
available.
MAX Displays the highest value of the field you select in the Field to Aggregate option for all
directly related records. Only number, currency, percent, date, and date/time fields are
available.
Examples of Roll-Up Summary Fields
1) Date Opportunity First Created – A roll-up field was created on the Accounts
object. The MIN of all Created Date fields on the Opportunities object
displays the earliest date an opportunity was created related to an
account.
2) Total Price of All Products Related to an Opportunity - A roll-up field was
created on the Opportunities object. Total Price is summarized on the
Opportunity Product object to find the grand total of all products
related to an opportunity
3) Minimum List Price of An Opportunity

Lesson 3 - Create Validation Rules

Validation rules verify that data entered by users in records meets the standards you specify
before they can save it. A validation rule can contain a formula or expression that evaluates
the data in one or more fields and returns a value of “True” or “False.” When the validation
rule returns a value of "True", this confirms that the data entered by the user contains an
invalid value.

Examples of Validation Rules

https://trailhead.salesforce.com/content/learn/modules/point_click_business_logic/validation_rules
?trailmix_creator_id=strailhead&trailmix_slug=prepare-for-your-salesforce-platform-developer-i-
credential

Part 3 - Data Modeling

https://trailhead.salesforce.com/content/learn/modules/data_modeling?trailmix_creator_id=strailh
ead&trailmix_slug=prepare-for-your-salesforce-platform-developer-i-credential

Lesson 1 - Optimize Customer Data with Standard and Custom Objects