Salesforce Fundamentals Flashcards
Describe the considerations when developing in a multi-tenant environment.
- Shared
- Metadata driven architecture
- code, configurations, apps,
- Metadata driven architecture
- Trusted Multitenant Cloud: At Salesforce, trust is our #1 priority, which is why our trusted, multitenant cloud is our foundation for everything we build.
Scalable, Metadata Platform: The secret sauce of our platform is its metadata-driven architecture. All customizations in the Salesforce schema, including code, configuration, apps, and more, are specified as metadata. In our architecture, we keep your metadata layer separate from our services layer, which allows us to give you seamless, easy upgrades.
Fast App Dev & Customization: That scalable metadata layer is what helps you go faster and get live quicker.
Largest Enterprise Ecosystem: Our partners in our ecosystem understand the value of that secret sauce, and this is a big part of the reason so many of them build on our platform.
Complete CRM: So what goes on top of all of this? Complete CRM functionality, so you can support your sales, service, analytics, marketing, community, and apps needs on our trusted platform.
API: Finally, we wrap it all up with a powerful suite of APIs, which allow you to develop and customize, and also give us the power to create things like the Salesforce1 Mobile App (more on this later).
Describe how the Salesforce platform features map to the MVC pattern.
- objects fields map to Model
- triggers, apex, map to Controller
- VF maps to View
Describe the capabilities of the core CRM objects in the Salesforce schema.
Leads:
Leads are people and companies that you’ve identified as potential customers. You find leads in a number of ways. Many of your leads might be referred to you by your other happy customers. You might also gather leads when customers contact you on your website, stop by your booth at a conference, or through information exchanges with partner companies. In Salesforce, information about leads is stored in Lead records.
- Determine if you will use leads
- Set up lead assignment rules
- Convert a lead
Sales/Oppty
- Describe how to use opportunities
- Set up a sales process
- Set up opportunity stages
- Create an opportunity
- Add Contact Roles to an opportunity
- Set up an Opportunity Team
Accounts and Contacts
- Describe what business accounts and contacts are, and explain how they’re related
- Describe what a person account is
- Add a new business account and associated contact
You need insight into your business and your data and that starts with the people you’re doing business with. In Salesforce, you store information about your customers using accounts and contacts. Accounts are companies that you’re doing business with, and contacts are the people who work for them.
If you’re doing business with a single person, like a solo contractor or an individual consumer, you use a special account type called a Person Account.
For the purposes of this module, we’ll assume you’re selling to businesses only, and your accounts are all business accounts. But almost everything you learn here can be applied to both types of accounts.
Accounts and contacts are related to many other standard objects, which makes them some of the most important objects in Salesforce. Understanding how to use accounts and contacts is key to getting the most out of Salesforce CRM.
Identify the common scenarios for extending an application’s capabilities using the AppExchange.
Follow these steps to develop your AppExchange strategy:
- Identify the departments using Salesforce (either now or in the future). These are your primary stakeholders for AppExchange app installations.
- Research AppExchange apps for the business cases provided by your stakeholders. Interview your stakeholders thoroughly to gather the requirements needed to select and evaluate the apps. Some good questions to ask include:
- What business problem are you trying to solve?
- What are your main pain points at present?
- How many users?
- What is your budget?
- What is your timeline?
- Download apps into a sandbox or Developer Edition org for preview and testing. An important step is to ensure that the app you’re installing doesn’t interfere with any customizations you’ve done or other apps you’ve already installed. This is also a good time to ensure you don’t already have an app installed that provides the same functionality.
- Note
- Sandboxes are copies of your organization in a separate environment. They are used for development and testing. See Sandbox Overview.
- Evaluate your choices. Consider budget, app functionality, and any feature gaps. Consider inviting your stakeholders into the sandbox or Developer Edition org to preview the app functionality, or invite your stakeholders to a demo of the app.
- Execute and document. Prepare your users for the change in user experience (if any), including providing training or documentation as needed.
Given a scenario, identify common use cases for declarative customization.
Scenario based question which will focus on test takers ability to identify whether to use formula, roll-up summary field, validation rule, workflow rule, process builder or approval process. Refer trailhead modules ‘process automation’ and ‘formula fields and validations’
Introduction to 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.
Formula Field Limits:
- Default value formulas for a record type can only reference fields for that record type. However, formula fields and formulas for approvals or rules for a record type can reference fields for that record type as well as any records that are related through a lookup or master-detail relationship. For example, a formula for a validation rule on opportunities can reference merge fields for accounts and campaigns as well as opportunities, and a formula field on accounts can reference fields for cases.
- You can’t use long text area, encrypted, or Description fields in formulas.
- The value of a field can’t depend on another formula that references it.
- You can’t delete fields referenced in formulas. Remove the field from the formula before deleting it.
- Campaign statistic fields can’t be referenced in formulas for field updates, approval processes, workflow rules, or validation rules, but can be referenced in custom formula fields.