Navigation Flashcards
Accounts and contacts
Used to store information about your customers. (Accounts are companies, and contacts are people that work at your accounts) (best practice : always associate contact with an account)
AppExchange
Marketplace for all things SF, apps, Lightning components, Flow solutions, and more.
AppExchange Strategy
Listing of apps, lightning components, flow solutions and more.
Scrum case study
The team can break down the work into the smaller projects.
Kanban case study
The team have to deal with service outages : example of interruption-driven work. You can’t know about your plan for outages 2 weeks in advance.
How do the serach functionality works in SF ?
All records are stored as data fields in the org’s database. When you update or create a record, the search engine comes along, makes a copy of the data, and breaks up the content into smaller pieces called tokens. We store these tokens in the search index, along with a link back to the original record.
SF APIs
SF Object Query Language (SOQL) Use SOQL when you know in which objects or fields the data resides
SF Object Search Language (SOSL) Use SOSL when you don’t know in which object or field the data resides
Send Queries with Protocols
You can write all the beautiful search queries that you want. But they aren’t any good unless you use an API protocol like REST, SOAP, or Apex to actually send them.
Keep in mind that some protocols get along better with some APIs than others. In general, we talk about queries with SOQL and searches with SOSL.
Lightning Experience
pages in Salesforce optimized for sales use
Lightning Experience
pages in Salesforce optimized for sales use
Kanban View
when setting up a kanban view, summarize each column by a key number or amount or none. Group the records into columns representing the progress you want to track.
User creation
a user license determines which features the user can access in SF. Fexmp : you can allow users access to standard SF features and Chatter with Standard SF License.
a Profile determines what users can do in SF, they come with a PS which grant access to particular things. it’s based on the user’s job function.
a Role determine what users can see in SF, regarding their location in the role hierarchy. Users at the top of the hierarchy can see all the data owned by users below them.
Organization–wide defaults
specify the default level of access that users have to each others’ records. You use organization–wide sharing settings to lock down your data to the most restrictive level, and then use the other sharing tools to selectively give access to other users.
Role hierarchies
open up access to those higher in the hierarchy so they inherit access to all records owned by users below them in the hierarchy. Instead, each role in the hierarchy represents a level of data access that a user or group of users needs.
Sharing rules
enable you to make automatic exceptions to organization–wide defaults for particular groups of users, to give them access to records they don’t own or can’t normally see. Sharing rules, like role hierarchies, are only used to give more users access to records—they can’t be stricter than your organization–wide default settings.
