Salesforce is a company, founded by Marc Benioff and Parker Harris in 1999, that specializes in software as a service (SaaS). Salesforce started by selling a cloud-based Customer Relationship Management (CRM) application, which laid the foundation for many of its future services and was built on the Salesforce Platform. Following this, the company began packaging other applications that were closely intertwined on the same platform and divided them into clouds. These cloud-based applications are now popularly known as Sales Cloud, Service Cloud, Marketing Cloud, IoT Cloud, Integration Cloud, Community Cloud, Health Cloud, and Financial Services Cloud, among others.
In this chapter, you will learn about the basic concepts of working on the Salesforce Platform. The material covered in this chapter represents 10% of the exam questions.
We'll learn about the following topics in this chapter:
We'll end the chapter with a summary and a quiz so that you can check whether you understand everything that you need to for the exam.
We've brieflymentioned what Salesforce is in the introduction, but it's also important to know what the Lightning Platform is before we start talking about multi-tenancy. The Lightning Platform is the infrastructure in which companies can enable one or more of the aforementioned cloud products, install apps from the AppExchange (the Salesforce store), or build their own custom apps.
Using the platform alone—that is, without one of the core cloud products such as Sales Cloud or Service Cloud—is also possible through Salesforce's platform as a service (PaaS) option. In a similar way to their CRM application, customers can pay a monthly fee to access the shared resources and build custom apps through PaaS.
The biggest benefits of using or buying a cloud service product is that everything is taken care of by the provider – that is, the servers, storage space, the infrastructure, networks, security, backups, and upgrades.
- They are subscription-based models
- They have low startup fees
- They have fixed and predictable costs (that is, you pay as you use the service)
- They are scalable
- They include regular, automated upgrades
- They are multi-tenancy platforms; this means that multiple customers use (or share) the same instance
These are important features to bear in mind when talking about multi-tenancy!
For example, consider a scenario, where you – as a company or a customer – rent an apartment in a block that is owned by Salesforce, who is your landlord:
Here, your apartment has specific layouts and resources – that is, it has a number of rooms divided by walls. In addition to this, it has central heating, electricity, water, and more. To access and use this apartment, you pay a monthly rent, and everything else is taken care of for you and the other occupants in the building by your landlord.
Apart from your apartment (which is your private space), all the other resources are shared by the occupants of the building. This means that if Salesforce decides to upgrade the central heating to underfloor heating, then you will automatically benefit from this. You can see this as three releases (that is, upgrades containing new features and enhancements) a year, which Salesforce implements.
Within your apartment, you can design your interior just the way that you want, and adjust it to your needs and personal preference! For instance, you can choose what room to have as your bedroom or your kitchen; or, alternatively, you can use the whole apartment as an office space. You can even paint the walls blue or flashy green if you want to. This is similar to using a Salesforce Platform, where once you have access to your space, you can then create new custom objects, add fields, and automate features to suit your business needs.
The only thing that you can't do is break down the walls – otherwise, the whole building will collapse, right? Even though you have full flexibility in rearranging your apartment, you are still limited when it comes to certain things! For example, you can't put in a 5-meter sofa if the size of the room is smaller than this; additionally, you can't put in a Christmas tree that is higher than the height of your room, or you would need to break the ceiling, and your neighbor would start a lawsuit against you. Alternatively, you can't just install multiple high-voltage accessories or machines in your apartment without the electricity box exploding and leaving the whole building without power!
I use this analogy in order to explain the governor limits that Salesforce enforces. Salesforce enforces these limits to make sure that no one single occupant will consume resources that could impact the other tenants or occupants who are using the Salesforce infrastructure.
Salesforce uses a multi-tenancy architecture, meaning that a number of organizations (orgs) share the same IT resources, as opposed to dedicated resources. This results in a standard environment that is fully operated and managed by Salesforce, which is much more efficient and cost-effective for your company.
- An application and database server
- A file server
- A server, storage, and network infrastructure
An org is an independent configuration (or metadata) and data that is dedicated to a customer. It is represented by a unique ID that you can find in the
Company Profile section in
Setup. You must provide this ID each time you contact Salesforce support for
Feature Request, and more. Each org only runs on one instance, which serves thousands of other orgs.
The org's unique ID is stored in every table in the shared database to allow the filtering of data, and to ensure that a client's data is only accessed by that client alone.
- All Salesforce customers, from small businesses to enterprise companies, are on the same code base and they all benefit from the same features and new functionality.
- Salesforce upgrades are easy, automatic, and seamless. There are three automatic upgrades a year, which are called the Spring, Summer, and Winter releases.
- With upgrades, a version is associated with every Apex trigger and Apex class. Here, backward compatibility is assured.
- Each class has a version associated with it called the API version. When you move to the next release, the Apex class always uses the older version of the compiler to guarantee this backward compatibility. Otherwise, you can modify the code to work on the newest version.
So, if all resources are shared by multiple customers, how does Salesforce ensure that one customer doesn't eat up all resources or break things that could impact all other customers on the same instance?
Salesforce controls this by enforcing two things, which can be considered as the side effects of multi-tenancy:
- Governor limits: These are the limits enforced by Salesforce that cannot be changed, and they are the same for anyone using the platform. For example, you can only use 100 queries in one execution context or perform 150 DML (short for Data Manipulation Language) statements in one execution context. Don't worry if you don't understand this yet, as we'll come back to this later. You can find the list of all the governor limits in the Salesforce documentation at https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm.
- Mandatory testing: Salesforce forces you to test your code before you are allowed to deploy it to production or upload a package to the AppExchange. At least 75% of all code must be covered by tests and they should all pass. Every trigger within your deployment package needs at least some coverage. It's best practice to test all possible scenarios, including positive and negative tests, in addition to testing for bulk updates or creation.
- An application's data storage (model)
- An application's user interface (view)
- An application's logic (controller)
The following diagram maps Salesforce's components to this architectural design:
This architecture is used a lot in software development because the isolation of data (that is, the model), user interface (that is, the view), and logic (that is, the controller) allows each component to be developed, tested, and maintained independently.
- Model: This is actually where your data is stored and can be used. To store data, you need objects or fields, and these are considered to be part of the model.
- View: This is whatever end users see and interact with; that is, what displays data to the clients or customers. This allows you to control how (and what) data is shown on the user interface. So, standard pages, page layouts, Visualforce pages, Lightning components, console layouts, and mini page layouts are all considered part of the view.
You could describe MVC like this—when you see a registration form (such as the Visualforce page developed on Salesforce), enter some information into the form, and then hit submit, the details are sent to a database and are saved into tables, columns, and rows (these are Salesforce objects and fields). Which data goes to what object and field in Salesforce is controlled by the logic defined in the standard and custom controllers.
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).
- 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:
A lead will always convert into a contact, and depending on whether you have
Person Accounts enabled in your org, an account will also be mandatory (either a new or existing account). If
Person Account is enabled, then the conversion process will convert your lead to a
Person Account if the
Company field is left empty. After the conversion process is successfully executed, the lead will be flagged as converted and will no longer be visible in the search results (unless your profile has the
View and Edit Converted Leads
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 Accountsin 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 Accountsare 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 Hierarchyfrom 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
Hierarchyoverview page, through
Hierarchy Columns. The following screenshot shows how
Account Hierarchyis presented to the user on the Salesforce interface:
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
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
ReportsToIdlookup 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
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.
AppExchange is the official Salesforce marketplace for business applications and is available at https://appexchange.salesforce.com/.
An app is a bundling of custom objects, fields, programmatic and/or declarative logic, and automations. They solve a specific business requirement or support a specific business process in a better way. You can install an app from AppExchange by simply clicking on the
Get It Now button and decide on whether to install a production or a sandbox environment.
So, what can you find on AppExchange? Well, let's take a look, as follows:
- Apps: These are groups of tabs, objects, components, and business logic that work together to provide standalone functionality.
- Lightning components: These are the building blocks of functionality that you can drag and drop into a Lightning app, on Lightning pages, or community pages through the Lightning App Builder interface.
- Flow solutions: If you want to automate your business process with flow actions, then Lightning flow is considered one of the most powerful, and more advanced, declarative automation tools. The chances are that somebody has already built some flow processes that meet your needs.
- Lightning bolt solutions: These are industry template solutions, which are mainly built by partners to help you market faster. Lightning bolts contain process flows, apps, Lightning components, and even whole communities.
- Lightning Data: These are pre-integrated, approved, and scalable data solutions. If you want to connect to a data source supplier, such as D&B, then first check whether there is a Lightning Data solution for it.
- Consulting partners: If you are looking for help implementing or expanding your Salesforce solution, then AppExchange contains a listing of all consulting partners worldwide, including reviews.
AppExchange is extremely easy to search—you just type in a keyword and it will start giving you suggestions. You can easily filter the search options according to industry to see what apps are popular in your industry. Additionally, you can filter by solution type, price, compatibility with your Salesforce edition, ratings, and language. It will even suggest you learning modules on Trailhead, the free online Salesforce learning platform!
- Is it free or paid? Does it fit within your budget?
- Is it compatible with your Salesforce edition?
- Does it require you to turn on some features that are not yet enabled in your org?
- Is it Lightning-compatible or does it only work in Classic?
- What do the reviews say? Are any of your requirements not met?
- Always test in a sandbox environment first!
When talking about AppExchange, it's important that we talk about packages, because that's what you will be installing—a package.
Packages are bundles of metadata components that make up an app or solution. A typical package will contain objects, fields, Workflow Rules (WFRs), validation rules, processes, approval processes, flows, Apex classes, Visualforce pages, and Lightning components. There could be hundreds of them in one package.
Packages are used for distribution across unrelated orgs—it's like deploying a change set.
In fact, anybody can create a package for distribution, and then share the link to someone else to install the solution in their org. These packages are private and the receiver must know the exact URL of the package to be able to install it.
If you want your package to be publicly available, searchable, and/or listed, then it must be uploaded on AppExchange.
- Unmanaged packages:
- They are used for distribution across orgs.
- By installing an unmanaged package, you copy all its contents into your org and, after installation, you can modify everything. You can change the Apex code, the Visualforce code, mark fields as required or not, change their data types, and more.
- The contents of the package become yours.
- This also means that the creator or provider loses all control and, in most cases, they cannot offer any support on the package.
- They don't need to have a namespace.
- The packaged components will count toward your org limits.
- Managed packages:
- The source code of managed packages is hidden from you
- You can't see or modify any of the code
- Managed packages can only be created in a developer environment
- This also means that the creator or provider has control over the installed version and can offer upgrades
- The provider will mostly provide support on the package
- You can grant the provider access to your org to support you, in the same way that you would grant access to the Salesforce support
- The packaged components do not count towards your orgs limits
- The use of a namespace is required
- Managed packages are typically for sale on the AppExchange
It's important to understand one of the biggest differentiators of Salesforce in comparison to other CRMs. Salesforce provides a lot of tools and features to maximize declarative customization (through point-and-click tools). In fact, while configuring Salesforce to suit your business needs, in 80% of cases, you will be able to solve your requirement with declarative functionality. For the remaining 20% of the use cases, you'll need some kind of programmatic development.
Becoming a certified platform developer does not mean that you solve everything with code. Customers, consultancy agencies, and Salesforce all expect a Salesforce developer to be able to use the easiest tool to achieve a solution and, therefore, most of the exam will assess whether you are able to distinguish what can be achieved through declarative configuration and what cannot be, hence, reverting to a more programmatic approach.
In Chapter 3, Declarative Automation, we'll dive deeper into ways to automate your business through declarative tools and programmatic options. For now, let's just recap the most commonly used declarative features that Salesforce offers an admin out of the box.
Consider the following screenshot; here, you can compare objects and fields by having an Excel file, where you have a sheet for every object, such as accounts, contacts, quotes, and so on. In this case, you will need to keep track of multiple records and specific data:
You will also need a row for each account record, along with columns for the data that you would like to track of for the account. In Salesforce, these are represented by fields. Just like in Excel, a field can have a certain data type depending on what type of data you are tracking—that is, text, phone numbers, URLs, dates, and more.
Each object can be, but doesn't have to be, represented by a tab in Salesforce, just like creating a sheet per object in Excel. Having a tab for the object gives you the benefit of creating filtered list views of records for that type of object.
Additionally, you can extend your database to your needs; this is done by creating new custom objects yourself and creating extra custom fields on the existing standard objects and/or on your newly created custom objects to track whatever data you deem necessary. While creating a field just like in Excel, you have the choice between several data types such as
Rich Text Area,
Master-Detail relationship Checkbox,
ormula fields, and
Roll-up Summary fields.
A formula field is like a real-time calculation that is calculated when it is loaded or requested. It's like a formula in an Excel spreadsheet. We refer to it as loaded or requested, because it's not a calculation that appears while viewing a record in the user interface. When you request the record data, it is calculated (or recalculated) using the following methods:
- By viewing it in the UI or in a report
- By exporting the data through a data loader
- By reading the data through an API call
- By querying the data in a SOQL query
A formula field is always read-only. This means that it's not a field in which you can type or change it's value manually – it is always calculated. As a result of this, the calculation does not perform an update on the record and this can never trigger any automations. What I mean here is that you can't have something like a WFR that updates a field when that field changes without performing a manual update or other automation update of the record. You can, however, use the value of a formula field in your automation processes as a criterion or to use as a value.
I know this is somewhat confusing, so let's try to explain it using an example. Let's say that we create a formula field returning a date that is calculated, based on the creation date of a record plus 30 days, and we would like to create a task for the owner when we reach that date automatically. You could be tempted to create a Process Builder that evaluates whether
TODAY() equals the date field. If it does, then create the task and, as long as that date is not equal, it's still either in the future or already past.
Now, if the record does not get updated by someone manually, or by some other automation, then nobody will touch this record and this Process Builder won't fire—this is because all automations only fire on the creation or updating of records.
Additionally, a formula field is calculated in real time when it gets requested and does not perform an update of the record. You can use your own logic in order to build the calculation that it needs to perform, and Salesforce offers a lot of functions for you to use within your formulas.
For instance, I really like the Formula Cheatsheet Salesforce that contains the most used functions. You can find it at https://resources.docs.salesforce.com/rel1/doc/en-us/static/pdf/SF_Formulas_Developer_cheatsheet_web.pdf.
A formula field can return the following things:
Formulas usually perform calculations with other values in the record that it resides on, but it can also use the values of parent records, or grandparent records, up to 10 levels up. However, it cannot use the values of child records. So, a common use case for a formula field is to display data from its parent. For example, let's say that we have a custom
Region__c, on the account page and we would like to show this value on our opportunities page. Because an opportunity is directly linked to an account, we could create a formula field that renders the text using the formula
Because a formula is always calculated in real time, this value will always represent the actual value from the
Region__c field of the account on our opportunity, without manually updating all opportunities of this account whenever the
Region__c field changes on the account.
A formula field that uses data from its parent, or higher up the hierarchy, is called a cross-object formula. Formulas do have some limitations that you need to be aware of; for example, you will get an error message if your formula does not comply with the following limits:
- The maximum number of characters is 3,900.
- The maximum formula size on saved is 4,000 bytes.
When your formula exceeds either of the aforementioned characters or byte limits, then you will receive an error message mentioning this.
A rollup summary field (RUS) field is very much like a formula field in that it also performs a calculation. However, this is based on child records, and only when these child records are part of a Master-Detail relationship!
It's used to summarize a numeric value based on (filtered) child records and can perform
It is recalculated whenever a transaction on these child records occurs in the following ways:
- When a new child is created
- When one of the children gets updated
- When a child gets deleted
You can use filters to only pull values from specific child records. For example, let's say that we have a custom
Invoice__c object that is related to the account as a Master-Detail relationship. In our
Invoice__c object, we have an
Amount field and a
Status field. We could create a RUS field in the account that represents the total amount that is overdue, which is a calculation of the
SUM operation of the
Amount field on all related invoices, with a filter on the
Status field that is equal to
Validation rules are used to make sure that the data entered in fields adheres to the standards you have specified for your business.; for example, making sure that phone numbers always have the same format, or that a field cannot be left blank based on the input or value of another field. If a value does not meet your validation rules, then the user will not be able to save the record. A validation rule is made of a formula or expression to check the criteria and an error message, which will be shown to the user if the values do not meet your specified criteria. The formula evaluates the data in one or more fields, and then returns either true or false. Validation rules ensure data quality in your org.
If the formula returns true, then the defined error message is displayed and the record cannot be saved. The formula can be referenced with more than one field and can also be a cross-object formula. While setting the error message, you can decide to show it next to a certain field or on top of the page.
Validation rules will run while performing operations through an API (through Data Loader, for example), on web-to-lead creations, and on web-to-case submissions. So, make sure that you design your validation rules so that they will not interfere unintentionally with these functionalities. In some scenarios, you may need to disable the validation rules while you import or update data, and then reactivate the rules afterward. Alternatively, you may exclude a specific user or profile in the validation formula so that it doesn't execute when the operation is run, as that specific user or as a user with that profile; this means that they can perform data loads without validation rules firing.
A WFR tool is one of the oldest and highest-performing automation tools. They help end users save time in their day-to-day activities. A WFR is a set of actions that need to be executed when a record is created or updated to meet specified criteria.
- Criteria: What must be the true record for the WFR to fire and have its associated actions to be executed
- Actions: What to do when the record meets the criteria that was defined and which actions need to be executed
- Sending an email alert
- Performing one or more field updates
- Sending an outbound message
- Creating a task
- Triggering a Lightning flow process
Consider the following screenshot:
Sometimes, you may want to create some kind of an approval process in which records need to be approved by one or multiple other users before moving further within your business process.
Well, approval processes are the tools that create these types of processes. They allow you to specify an object, the criteria (or record values) that need to be evaluated before a record must be submitted for approval or not, and who needs to give their approval. After an approval or rejection, you can perform a number of automated actions, such as field updates or sending notifications. In approval processes, after submitting the record, the record is then locked. In this way, nothing can be changed until the data has been approved or rejected.
The user who is submitting the data for approval can also have the option to recall the record, which takes the record back out of the approval process.
In the day-to-day life of end users, a lot of repetitive work is done manually. You can minimize these manual actions (such as sending email notifications, assigning records to other users or queues, and performing record updates to certain stages and statuses) by creating automated actions through the Process Builder. The Process Builder is one of the most powerful tools that you can use to automate your business using a nice graphical interface.
- When a record is created or updated in Salesforce
- When a platform event occurs on the Salesforce Platform
- When another process invokes it
Each process consists of nodes and actions, as follows:
- In the nodes, you'll define the criteria on which a set of actions need to be executed.
- The actions (immediate or scheduled, that is, time-based actions) need to be executed when a certain criteria node is being entered and evaluated (being true). Pay attention to the fact that only record-change processes support scheduled actions.
- Create records of any object type.
- Update any related record; this is not limited to the record itself or its parent.
- Use quick actions to create or update records or log calls.
- Invoke a process from another process.
- Launch a flow.
- Send an email.
- Post to Chatter.
- Submit a record for approval.
- Call an Apex class.
The Process Builder also comes with an easy-to-read and easy-to-edit drag and drop graphical interface; this is why most people call it WFR on steroids:
When it comes to flows, you might have heard of several different definitions or types. To clear up any confusion, the official terms are as follows:
- Lightning flow: This is the native platform feature that allows you to build, manage, and run processes
- Cloud Flow Designer: This is the graphical interface that is used to design and build your flows; this is done through clicks and dragging and dropping
- Flow: This is an actual chain of events, input captures, queries, and actions that will be executed to automate your specific business process when an event takes place in your Salesforce org or on an external system
In short, the Cloud Flow Designer is the tool that helps you create flows:
The flowscreen example
Every flow consists of three blocks, as follows:
- Elements (1): These are dragged onto the canvas; an element can represent a screen input, a query or some kind of action (such as
create record), a post to Chatter, and more.
- Connectors (2): These are used to define the order in which elements are executed. They form the path that elements must follow, and they tell the flow what elements must be executed next.
- Resources (3): These are pieces of storage in the memory of the flow that contain a specific value, such as values from fields or formulas. You can refer to and use these resources throughout your flow; for example, to look for an account's ID, store that ID in a variable resource with a name of your choice, and then later use that ID to update the account or to relate records to that account ID.
So, Lightning flow is an ideal tool for building—such as for call scripts, in which you guide users through a set of questions to ask a customer and, then, depending on the response, it performs a set of actions at the end of the flow. Additionally, Lightning flow is the only automation tool that is able to delete records.
Salesforce has a very nice comparison chart of the different automation tools, which you should know by heart for the exam. You can keep checking for any updates to this chart at https://help.salesforce.com/articleView?id=process_which_tool.htm&type=5.
Consider the following screenshot:
So far, we have learned how working on a multi-tenant platform requires your attention while developing your own custom applications. Additionally, we have learned what the MVC paradigm is, how Salesforce comes with some core standard objects, how you can create your own custom objects, and how you can leverage declarative tools to customize and automate your environment to support your business processes.
In Chapter 2, Understanding Data Modeling and Management, we'll learn more about the Salesforce data model and how you can extend it. Additionally, we'll explore how to relate different objects to each other, how to visualize these different relationships, how you can import data into the platform, and how to export it. We'll be building our own basic international movie database in order to explore all of these concepts.
But, first, let's check whether you are on the right track to becoming a certified Salesforce developer—I definitely hope so!
You'll find all the answers to each chapter summary quiz at the end of this book (in the Appendix). Try to answer the questions first without looking at the answers:
- Your manager wants you to build a solution that deletes all open tasks related to an opportunity when the
Opportunitystage is set to
Closed Won. In what ways could you build out this solution? Select two answers:
- Write an Apex trigger that fires when the
ortunity Stageupdates to
Closed Won, queries all the related
Tasksthat have an
Openstatus for that opportunity and then deletes them.
- Create a Process Builder that performs a delete action on all the related
Status Open, when the
Opportunity Stageis set to
- Create a Process Builder that calls a Lightning flow whenever an
Closed Won. The flow then queries all
Tasksrelated to the opportunity that kicked off the Process Builder with a status of
Open, and deletes them.
- Create a Process Builder that calls an Apex trigger whenever an
Closed Won. The trigger then queries all related
Taskswith a status of
Openfor that opportunity and deletes them.
- Write an Apex trigger that fires when the
- Object B has a master-detail relationship to object A, so A is the parent of B. You want to display the value of the
Status field from object A on the record of object B. How could you do this?
- You create a formula field on object B and, in the formula, you reference the
Statusfield from its related object A.
- You create an Apex trigger on object B to copy over the value of the
Statusfield from its related object A record.
- You create a RUS field on object B, pulling in the
Statusfrom object A.
- You use the Process Builder to fire off on object B to copy over the value of the
Statusfield from its related object A record.
- You create a formula field on object B and, in the formula, you reference the
- A business user would like you to send a notification whenever a case is put in the Closed status to the case owner's manager, and to post this on Chatter. What's the best tool to use?
- Apex trigger
- The Process Builder
- Lightning flow
- A cross-object formula field can be one of the following:
- Reference fields from parent objects that have a Master-Detail relationship
- Reference fields from parent objects related through a lookup relationship only
- Reference fields from parent objects related through either a Master-Detail or a lookup relationship
- Reference fields from the same record only
- Your company is in need of a recruitment application for its HR department including jobs, job postings, applicants, and more. How would you go about this?
- You start by drawing the data model, create the objects, test them, validate them, and perform a RUS calculation
- You start by searching the AppExchange
- You advise HR management that this is not something that should reside in Salesforce
- You scratch your head because you have no clue how to start providing a solution for this requirement
- What are some implications of a multi-tenant environment when it comes to Salesforce?
- Resources are added to the instance whenever needed, so you should not worry about resource consumption
- Multi-tenant means that your org gets its own instance with all its resources dedicated to your org
- You should avoid using Salesforce at peak time as it is slower than usual, because everybody is using it at that time
- There are governor limits imposed by Salesforce on each org to prevent them consuming all of the instance resources
- In a multi-tenant environment, which of these statements is true?
- Your org shares a Salesforce instance with thousands of other orgs
- Your org shares a Salesforce instance with no more than 100 other orgs
- Your org has its own Salesforce instance
- All Salesforce orgs use the same Salesforce instance
- What's special about a formula field?
- It is calculated once every 24 hours
- It is calculated once every hour
- It is calculated only when you write the record into the database
- It is calculated every time when you read the record in question
- How is a managed package built?
- Through your Salesforce org's sandbox
- Through the enterprise edition of the Salesforce org
- Through the developer edition of the Salesforce org
- Through a Salesforce developer edition's sandbox
- Your company asks you to create a process that automates holiday requests. There should be two levels of acceptance before the holiday request is granted—first, by the direct manager of the requestor, and then by the HR manager. How would you do this?
- Build a flow using the Lightning flow
- Build rules by using WFRs to streamline the process
- Build a process by using the Process Builder
- Build this process by using the approval process