[Deepak]

Change Sets. Use change sets to send customizations from one Salesforce org to another. For example, you can create and test a new object in a sandbox org, then send it to your production org using a change set. Change sets can contain only modifications you can make through the Setup menu.

[Deepak]

The lightning namespace components are optimized for common use cases. Beyond being equipped with the Lightning Design System styling, they handle accessibility, real-time interaction, and enhanced error messages. force tags works as apex:inputField tags work on the VF page. For example, if we are using forceInputField for the picklist field then it will show the input in picklist format with the respected values. It also supports the lookup/master input fields. A lightning tag has inbuilt SLDS we do not need to put extra effort to improve the look and feel, We can handle bad input and provide user validations.

[Deepak]

1. Both action support and action function can be used to call a controller method using an AJAX request.
* for example call controller onclick of a inputcheck box
* or call a controller method onfocus of a input field
Well, they both do the same thing of calling controller method.

Difference between both:

1. Action function can call the controller method from java script.
2. Action support adds AJAX support to another visualforce component and then call the controller method.
for example:

<apex:outputpanel id="outptpnl">
<apex:outputText value="click here"/>
<apex:actionSupport event="onclick" action="{!controllerMethodName}"  rerender="pgblck" />
</apex:outputpanel>

Here action support adds AJAX to output panel, so once you click on output panel controller method will be called.

3. Action function cannot add AJAX support to another component. But from a particular component which has AJAX support(onclick, onblur etc) action function can be called to call the controller method.
Example:

<apex:actionFunction name="myactionfun"  action="{!actionFunMethod}" reRender="outptText"/>
<apex:inputcheckbox onclick="myactionfun" />

In this example onlick of input checkbox "myactionfun" action function is called from where controller method "actionFunMethod" gets called.
Apart from this, the main difference between the "two" action support and action function is that, the action function can also be called from java script.
Example:

<apex:actionFunction name="myactionfun"  action="{!actionFunMethod}" reRender="outptText"/>
<apex:inputcheckbox onclick="myJavaMethod()" />
<script>
function myJavaMethod(){
myactionfun();// this call the action function
}
</script>

[Deepak]

When users request Salesforce data from within the external app (the consumer’s page), Salesforce authenticates the user. The authentication flow consists of several steps, dictated by the OAuth standard and who is trying to access Salesforce.

Digging Deeper into OAuth 2.0 in Salesforce
OAuth (Open Authorization) is an open protocol that provides secure API authorization from applications in a simple and standardized way. OAuth can authorize access to resources without revealing user credentials to apps. Apps that use OAuth can also directly authenticate and access Salesforce resources without a user’s presence.
OAuth 1.0.A Authentication Flow
OAuth 1.0.A has a single authentication flow. The diagram displays the authentication flow steps for OAuth 1.0.A.
OAuth 1.0.A Error Codes
On error, Salesforce returns an error code during the OAuth 1.0.A authentication flow.
OAuth 2.0 SAML Bearer Assertion Flow
The OAuth 2.0 SAML bearer assertion flow defines how a SAML assertion is used to request an OAuth access token when a client wants to use a previous authorization. Authentication of the authorized app is provided by the digital signature applied to the SAML assertion. A SAML assertion is an XML security token issued by an identity provider and consumed by a service provider. The service provider relies on its content to identify the assertion’s subject for security-related purposes.
OAuth 2.0 JWT Bearer Token Flow
In some cases, you want to authenticate servers without interactively logging in each time the servers exchange information. For these cases, you can use the OAuth 2.0 JSON Web Token (JWT) bearer flow. This flow requires prior authentication of the client app.
OAuth 2.0 Refresh Token Flow
The OAuth 2.0 refresh token flow renews tokens issued by the web server or user-agent flows.
OAuth 2.0 Web Server Authentication Flow
Apps that are hosted on a secure server use the web server authentication flow. A critical aspect of the web server flow is that the server must be able to protect the consumer secret. You can use code challenges and verifier values in the flow to prevent authorization code interception.
OAuth 2.0 Username-Password Flow
Use the username-password authentication flow to authenticate when the consumer already has the user’s credentials.
OAuth 2.0 User-Agent Flow
With the OAuth 2.0 user-agent authentication flow, users authorize your desktop or mobile app to access their data. Client apps that run on a device or in a browser use this flow to obtain an access token.
OAuth 2.0 Device Authentication Flow
The OAuth 2.0 device authentication flow is typically used by applications on devices with limited input or display capabilities, such as TVs, appliances, or command-line applications. Users can connect these client applications to Salesforce by accessing a browser on a separate device that has more developed input capabilities, such as a desktop computer or smartphone.
OAuth 2.0 Asset Token Flow
Client applications use the OAuth 2.0 asset token flow to request an asset token from Salesforce for connected devices. In this flow, an OAuth access token and an actor token are exchanged for an asset token. This flow combines asset token issuance and asset registration for efficient token exchange and automatic linking of devices to Service Cloud Asset data.
SAML Assertion Flow
The SAML assertion flow is an alternative for orgs that are currently using SAML to access Salesforce and want to access the web services API the same way. You can use the SAML assertion flow only inside a single org. You don’t have to create a connected app to use this assertion flow. Clients can use this assertion flow to federate with the API using a SAML assertion, the same way they federate with Salesforce for web single sign-on.
Scope Parameter Values
The scope parameter fine-tunes the permissions associated with the tokens that you’re requesting. Scope is a subset of values that you specified when defining the connected app.
OAuth Custom Scopes
A connected app can use the OAuth authorization protocol to access protected resources. As part of the protocol, OAuth default scopes fine-tune the app’s permissions to access protected resources in Salesforce. However, these default scopes are insufficient when an external entity is hosting the protected resource. In this scenario, Salesforce plays the role of OAuth authentication and authorization provider, but it has little knowledge about the resource it’s protecting. To define a connected app’s permissions to access protected resources hosted by an external entity, create an OAuth custom scope. The custom scope tells the external entity which information the connected app is authorized to access.
Revoke OAuth Tokens
Revoke an OAuth token if you don’t want the client app to access Salesforce data or if you don’t trust the client app to discontinue access on its own.
Use the Access Token
You can use the access token in either the HTTP authorization header (REST API or Identity URL) or the SessionHeader SOAP authentication header, (SOAP API).
Get and Verify an ID Token
The ID token is a signed data structure that contains authenticated user attributes, including a unique identifier for the user and when the token was issued. It also identifies the requesting client app. The ID token is defined by OpenID Connect.
Identity URLs
An identity URL uniquely identifies the current Salesforce user. You can also use it in an HTTP request to get more information about the user.
UserInfo Endpoint
OpenID Connect defines the UserInfo endpoint to get a user’s profile information.
Prepare for Dynamic Client Registration
Before you can automatically register OAuth 2.0 connected apps with Salesforce using the dynamic client registration endpoint, you must complete the following prerequisites.
Generate an Initial Access Token
OpenID Connect dynamic client registration lets OAuth 2.0 clients (connected apps) automatically register child connected apps with Salesforce. To authenticate these client registration requests, Salesforce requires an initial access token.
OpenID Connect Dynamic Client Registration Endpoint
OpenID Connect dynamic client registration lets OAuth clients automatically register OAuth 2.0 connected apps with Salesforce. For example, Mulesoft (an OAuth client) can send a request to the dynamic client endpoint to register a new child OAuth 2.0 connected client app with Salesforce. With a successful registration, Salesforce returns a new client identifier and metadata about the newly registered child OAuth 2.0 connected client app.
OpenID Connect Token Introspection Endpoint
OpenID Connect token introspection enables OAuth 2.0 connected client apps to check the current state of an OAuth 2.0 access or refresh token.
OpenID Connect Discovery Endpoint
Use the OpenID Connect discovery endpoint to query for information about the Salesforce OpenID Connect configuration.
Authentication Configuration Endpoint
The authentication configuration endpoint is a static page that you can use to query for information about an org’s SAML for single sign-on and authentication provider settings. No session is required. It’s available only for Salesforce communities or orgs with My Domains. Use this URL when you’re developing apps that need this information on deman

[Deepak]

The “View All” and “Modify All” permissions ignore sharing rules and settings, allowing administrators to grant access to records associated with a given object across the organization. “View All” and “Modify All” can be better alternatives to the “View All Data” and “Modify All Data” permissions. When you grant “View All” or “Modify All” for an object on a profile or permission set, you grant any associated users access to all records of that object regardless of the sharing and security settings

• This reply was modified 5 years, 2 months ago by  Deepak.

[Deepak]

Messages can be displayed in notices and toasts. Notices alert users to system-related issues and updates. Toasts enable you to provide feedback and serve as a confirmation mechanism after the user takes an action.

Include one <lightning:notificationsLibrary aura:id="notifLib"/> tag in the component that triggers the notifications, where aura:id is a unique local ID. Only one tag is needed for multiple notifications.

Notices
Notices interrupt the user's workflow and block everything else on the page. Notices must be acknowledged before a user regains control over the app again. As such, use notices sparingly. They are not suitable for confirming a user’s action, such as before deleting a record. To dismiss the notice, only the OK button is currently supported.

Notices inherit styling from prompts in the Lightning Design System.

To create and display a notice, pass in the notice attributes using component.find('notifLib').showNotice(), where notifLib matches the aura:id on the lightning:notificationsLibrary instance.

Here’s an example that contains a button. When clicked, the button displays a notice with the error variant.

<aura:component>
<lightning:notificationsLibrary aura:id="notifLib"/>
<lightning:button name="notice" label="Show Notice" onclick="{!c.handleShowNotice}"/>
</aura:component>

[Deepak]

A change in a child component can be communicated to the parent component via component event. Component events are used to do communication between child and parent. Application events are used to communicate any change in the component to a broader audience. Any component who has registered for this event will get a notified. They use bubbling and capture same as used in DOM events.

[Deepak]

The four basic types, apex:pageBlockTable, apex:dataTable, apex:dataList, and apex:repeat are all basically the same thing, but present different renderings.

apex:pageBlockTable represents a table formatted and styled to look like a related list table.

apex:dataTable is an unstyled table suitable for use anywhere outside of a apex:pageBlock (but may be used within one).

apex:dataList renders a ul or ol element (unordered or ordered list, respectively), with li (list item) elements comprising the rows.

apex:repeat allows any arbitrary output based on a template. The four elements require value and var attributes, iterate over a collection of some sort, may generally be nested inside each other, and are limited to 1,000/10,000 rows of output, depending on the apex:page's readOnly attribute.

Edit: As pointed out in the comment, the main difference with apex:pageBlockTable, compared to the other three, is it must appear in a apex:pageBlock or apex:pageBlockSection, while the other types can be rendered anywhere that Visualforce is allowed. There's a very specific limitation about apex:pageBlock not being available in email templates, as well, so you'd naturally have to use one of the other three types of iterators.

[Deepak]

Workflows in Salesforce are a fantastic way to automate certain business processes. You can create a rule, and based on certain criteria that you set, Salesforce can do a number of things, like send an email, create a task, or update a field. In this blog post, I’ll walk through setting up a workflow rule, using one of Newfangled’s rules as an example.

As you may know from recent blog posts by Chris Creech, we’ve implemented a marketing automation platform that integrates with and complements our Salesforce implementation.

We still use Salesforce to manage sales, and as our main repository for our database of leads and contacts. Marketing automation has allowed us to implement some pretty robust lead scoring rules, which means we now have a way to separate out qualified leads without having to do much manual work on our part.

Things were going great as we reaped the newfound benefits of marketing automation. Lead scoring rules were pushing qualified leads to the top of the list. But one thing was missing—automatic notification. In order to check out these ‘hot’ leads, we had to log into either Salesforce or Act-On. What we wanted was an email notification when someone had hit our ‘hot lead’ threshold.

While I’m sure some marketing automation platforms include this functionality, Act-On does not. But no big deal—I just logged into Salesforce and built a quick workflow to send out an email.

A note before we dive in: Remember that while this blog post was inspired by a particular need in our company to create a very specific workflow, you can create workflows in Salesforce based on an update to any field, and have those rules trigger many different types of actions. In addition to the rule I’ll describe here, we have a number of other workflow rules running in our Salesforce org.

Also be advised that workflow functionality is only a standard offering for the Enterprise and Unlimited editions of Salesforce.

Creating a workflow rule
A workflow in Salesforce is a great way to automate business processes. In order to create a workflow rule, you need 2 things:

Criteria that cause that rule to run (in this case, when a person’s lead score hits a certain number)
Actions that execute when a record matches the criteria (in this case, an email alert)
Navigate to Your Name > Setup > App Setup > Create > Workflow & Approval > Workflow Rules.

Select “New Workflow Rule” and then select the object you want the rule to apply to. We are interested in leads.

Name your rule, and give it a description. I named my rule “Act-On Lead Score Email Alert,” and described it thusly: “Send an email alert when a lead’s Act-On score exceeds 50.”

Next, decide on your evaluation criteria. There are 3 options here.

Salesforce will evaluate the rule when a record is:
1. created
2. created, and every time it’s edited
3. created, and every time it’s edited to subsequently meet criteria.

The first option will only check if the rule applies when the lead is created, which means it will ignore updates to existing leads. This definitely doesn’t apply, since we want our rule to apply to existing records.

The second option means that if the rule criteria is met, the rule will run, no matter what. Say we have a lead whose lead score is greater than 50. The rule will run when the record is edited to show that the lead score is above 50, but the rule will also run every single time that record is edited for any reason and the lead score is still above 50. This will result in an email about that lead, even after it’s already been determined that they’re a hot lead.

The third option means that the rule will run if a new record is created that meets the criteria, or if an existing record is changed from not meeting the criteria to meeting the criteria. This is the best option for our rule. If a hot lead is added as a new record, we’ll receive an alert. If a record is subsequently updated to have a lead score over 50, we’ll receive an alert only once that happens.

Next, set your rule criteria.

We’ve chosen:

Field: Act-On Lead Score
Operator: greater or equal
Value: 50
You can choose to add filter logic here, if need be. Perhaps in the future we will only want an email kicked out for leads who have an email address at a company. We would add another criterion that ignores emails from Gmail, Yahoo, etc. and then we would add ‘AND’ filter logic so that both of those criteria have to be met for the rule to run.

Here’s our finished rule:

Setting up workflow actions
Now that you’ve set up your rule, you need to specify the workflow actions that the rule will trigger. On the detail page for your rule, there will be a section called ‘Workflow Actions’—clicking Edit, and then Add Workflow Action, will present you with a dropdown menu of the actions available. I won’t go through the details of setting up each of these specific actions, but I’ve included the link to the Salesforce Help & Training document for each, in case you need further instructions.

New Task
New Email Alert
New Field Update
New Outbound Message (this action allows you to send a SOAP message with field values to an endpoint such as an external server)
Select Existing Action (this action allows you to use workflow actions you’ve created for other workflow rules or approval processes to be associated with your new rule)

[Deepak]

Time- Dependent Workflow actions: These are the actions we are more interested in.Time Depended Actions are executed when the specific time selected is selected, when defining a time trigger, use standard and custom date and date/time fields defined for the object.

[Deepak]

To define a connected app’s permissions to access protected resources hosted by an external entity, create an OAuth custom scope. The custom scope tells the external entity which information the connected app is authorized to access. A connected app can use the OAuth authorization protocol to access protected resources. As part of the protocol, OAuth default scopes fine-tune the app’s permissions to access protected resources in Salesforce. However, these default scopes are insufficient when an external entity is hosting the protected resource. In this scenario, Salesforce plays the role of OAuth authentication and authorization provider, but it has little knowledge about the resource it’s protecting.

[Deepak]

Without this interface, the component doesn’t appear as a pre-chat page option in Snap-ins Setup. Use this interface with the lightningsnapin:prechatAPI component to enable customization of your pre-chat user interface experience in Snap-ins for web. This interface is used to indicate that a component can be used with Snap-Ins Pre-Chat.This interface is a marker interface. A marker interface is a signal to the component’s container to add the interface’s behavior to the component. You don’t need to implement any specific methods or attributes in your component, you simply add the interface name to the component’s implements attribute.In this case, the interface doesn’t add behavior but makes the custom component available as a pre-chat page from Snap-ins Setup.

[Deepak]

It will return true if the variable is empty on which it is applied

[Deepak]

After users complete the login flow, they’re logged in to your Salesforce org or community. The login process can also log out users immediately if necessary. Login flows allow admins to build post-authentication processes to match their business practices, associate the flow with a user profile, and send the user through that flow when logging in. Salesforce directs users to the login flow after they authenticate but before they access your org or community.

[Deepak]

The data in the external table can be searched and referenced in Salesforce using custom tabs and federated search.An external lookup relationship links a child standard, custom, or external object to a parent external object.External objects are similar to custom objects, except that they map to data located outside Salesforce. Each external object relies on an external data source definition to connect with the data outside Salesforce. Each external object definition maps to a table that contains the data, and the object fields map to accessible table columns.

[Deepak]

An s-control can contain any type of content that you can display or run in a browser, for example, a Java applet, an ActiveX control, an Excel file, or a custom HTML Web form.S-controls provide a flexible, open means of extending the Salesforce user interface, including the ability to create and display your own custom data forms. Whether you are integrating a hosted application of your own or are extending your current Salesforce user interface, use s-controls to store your code or refer to code elsewhere.Use s-controls to add your own functionality to your Salesforce organization.

[Deepak]

The Bulk API provides a programmatic option to quickly load your org’s data into Salesforce. To use the API requires basic familiarity with software development, web services, and the Salesforce user interface.
The functionality described is available only if your org has the Bulk APIfeature enabled. This feature is enabled by default for Performance, Unlimited, Enterprise, and Developer Editions.

When to Use Bulk API
Bulk API is based on REST principles and is optimized for loading or deleting large sets of data. You can use it to query, queryAll, insert, update, upsert, or delete many records asynchronously by submitting batches. Salesforce processes batches in the background.

SOAP API, in contrast, is optimized for real-time client applications that update a few records at a time. You can use SOAP API for processing many records, but when the data sets contain hundreds of thousands of records, SOAP API is less practical. Bulk API is designed to make it simple to process data from a few thousand to millions of records.

The easiest way to use Bulk API is to enable it for processing records in Data Loader using CSV files. Using Data Loader avoids the need to write your own client application.
Bulk API 2.0
Salesforce provides an additional API, Bulk API 2.0, which uses the REST API framework to provide similar capabilities to Bulk API. Use Bulk API 2.0 instead of Bulk API if you want a simplified process for inserting, updating, upserting, or deleting large sets of data. Bulk API 2.0 does not currently support query or queryAll.

For more information on Bulk API 2.0, see the Bulk API 2.0 Developer Guide.
What You Can Do with Bulk API
The REST Bulk API lets you query, queryAll, insert, update, upsert, or delete a large number of records asynchronously. The records can include binary attachments, such as Attachment objects or Salesforce CRM Content. You first send a number of batches to the server using an HTTP POST call and then the server processes the batches in the background. While batches are being processed, you can track progress by checking the status of the job using an HTTP GET call. All operations use HTTP GET or POST methods to send and receive CSV, XML, or JSON data.

Currently base64 fields are not supported in queries with the Bulk API.
How Bulk API Works
You process a set of records by creating a job that contains one or more batches. The job specifies which object is being processed and what type of operation is being used. A batch is a set of records sent to the server in an HTTP POST request. Each batch is processed independently by the server, not necessarily in the order it is received. Batches may be processed in parallel. It's up to the client to decide how to divide the entire data set into a suitable number of batches.

A job is represented by the JobInfo resource. This resource is used to create a new job, get status for an existing job, and change status for a job. A batch is created by submitting a CSV, XML, or JSON representation of a set of records and any references to binary attachments in an HTTP POST request. When created, the status of a batch is represented by a BatchInfo resource. When a batch is complete, the result for each record is available in a result set resource.

Processing data typically consists of the following steps.Create a new job that specifies the object and action.
Send data to the server in a number of batches.
Once all data has been submitted, close the job. Once closed, no more batches can be sent as part of the job.
Check status of all batches at a reasonable interval. Each status check returns the state of each batch.
When all batches have either completed or failed, retrieve the result for each batch.
Match the result sets with the original data set to determine which records failed and succeeded, and take appropriate action.

[Deepak]

$A is how you gain access to the underlying Aura framework, such as enqueuing actions, getting application events, managing the Aura rendering life cycle, and various utility methods. You can view the available methods using AuraDocs, located on your server at /auradocs/reference.app. You can access it using the production or sandbox links I've provided here. You'll find the full list in the JavaScript API section.

[Deepak]

Scontrols:-S-controls have been superseded by Visualforce pages. After March 2010 organizations that have never created s-controls, as well as new organizations, won't be allowed to create them. Existing s-controls will remain unaffected, and can still be edited. We recommend that you move your s-controls to Visualforce. We continue to support the Scontrol object.

Visualforce:-Visualforce is the new force.com technology that lets you create custom user interfaces for your Force.com applications. With Visualforce, you can reuse many of the components found in existing Salesforce interfaces, or create your own. Moreover, the interfaces can also tap into custom business logic. The technique is powerful, easily customized, separates business logic from user interface design, and in most cases eliminates the need for S-Controls. The custom pages can either complement and extend existing pages on Salesforce, or have their own unique look and feel.

 

The trinity of the existing Force.com platform together with Visualforce and their associated controllers provide a way to construct traditional MVC web applications, albeit hosted on the Force.com platform.

 

difference between Visualforce and S-control:-

Scontrols get executed in the browser client-side. It is definitely recommended to implement Visualforce pages instead of SControls for user-interface customizations.

[Deepak]

Custom settings are similar to custom objects. We have to create our own custom setting similarly to creating custom object.).Custom settings are similar to custom objects and enable application developers to create custom sets of data, as well as create and associate custom data for an organization, profile, or specific user. The custom setting data can then be used by formula fields, validation rules, flows, Apex, and the SOAP API.

[Deepak]

Use "Hard Delete" option and the records are not recoverable via the Recycle Bin.

[Deepak]

Identify which fields to display in an approval request post.

REQUIRED EDITIONS AND USER PERMISSIONS
Available in: both Salesforce Classic and Lightning Experience
Available in: Enterprise, Performance, Unlimited, and Developer Editions

USER PERMISSIONS NEEDED
To create approval request post templates:
Customize Application
From Setup, enter Post Templates in the Quick Find box, then select Post Templates.
Click New Template.
Select the object for your template.
Click Next.
Give the template a name and description.
If you want this template to be the default for the associated object, select Default.
Add up to four fields to display on the approval request post.We recommend putting any text-heavy fields—such as Comments or Description—at the bottom.
Save your changes.

[Deepak]

Outlook to Salesforce Integration has been explained in a trailhead module please refer:

https://trailhead.salesforce.com/en/content/learn/modules/outlook_integration/outlook_integration_unit_3

[Deepak]

To set up a dynamic dashboard, create a folder to hold the dashboard and its underlying reports, then create the dashboard. Your organization can have up to 5 Enterprise Edition, 10 for Unlimited and Performance Edition, and 3 for Developer Edition. You can't save dynamic dashboards to personal folders.

refer:

https://www.ajaydubedi.com/tutorials/salesforce-advance-administrator-notes-dashboards/

[Deepak]

Webhooks
Webhooks are notifications about QuickBooks entities that are sent to developer-created applications.

If you wish to be notified when a customer’s information changes, you may configure a specific endpoint that QuickBooks can call for this event with the details of the change.

When webhooks is active, data for the requested event is aggregated and then sent in a periodic notification to your call back URL or service. Once you have configured webhooks, you will receive event notifications for all companies your app is connected to.

refer:

https://developer.intuit.com/app/developer/qbo/docs/develop/webhooks