Salesforce Integration Interview Questions Platform Event Part-4

1) What is the purpose of Salesforce Streaming API?

The Salesforce Streaming API enables real-time data updates using push technology and an event-driven architecture. It operates on an event-based model, allowing applications to subscribe to events and receive updates as they occur in near real-time.

2) What types of events are supported by the Salesforce Streaming API, and in which scenarios should it be used?

Types of Events Supported:

1. Generic Events: Legacy, for custom notifications.
2. PushTopics: Legacy, for changes in Salesforce records based on SOQL queries.
3. Change Data Capture (CDC): For tracking changes to Salesforce data records in real-time.
4. Platform Events: For high-volume, custom business event notifications.

When to Use the Streaming API:
Use Streaming API when real-time data updates are required to synchronize external systems with Salesforce data, such as in applications that react immediately to changes in data or business processes.

Note: PushTopics and generic events are legacy products with limited support. For new implementations, use Change Data Capture instead of PushTopics and Platform Events instead of generic events.

3) What are platform events in Salesforce?

Platform events are secure and scalable messages used to enable real-time communication between Salesforce and external apps, as well as within Salesforce itself, using an event-driven messaging architecture.

4) What is the Event Bus in Salesforce?

The event bus is a temporary storage system where platform event messages are published. Events on the bus can be retrieved using a CometD client, and each event contains a ReplayId field to identify its position in the stream.

5) What are standard platform events, and how can they be used?

Standard platform events, such as AssetTokenEvent and BatchApexErrorEvent, are predefined by Salesforce for specific purposes like monitoring authentication or reporting errors. Custom platform events can also be defined and published using Apex, Process Builder, Flow Builder, or APIs, and subscribed to via triggers or external apps.

6) How are platform events published in Salesforce?

Platform events can be published:

• Immediately: Messages are sent as soon as they are generated and cannot be rolled back.
• After Commit: Messages are sent only after a transaction is committed, and they support rollback using setSavepoint() and rollback().

7) What are high-volume platform events, and how are they different from standard-volume events?

High-volume platform events, introduced in API version 45.0, allow for better scalability and can handle millions of events. They are always published asynchronously for efficient processing. Standard-volume events are no longer available for new definitions but are supported for existing implementations.

8) What is the retention period for platform event messages on the event bus?

• High-Volume Events: Retained for 72 hours (3 days).
• Standard-Volume Events: Retained for 24 hours (1 day).

9) What is the ReplayId field in platform event messages?

The ReplayId field is a system-generated, opaque identifier for an event in the stream. It helps subscribers retrieve missed events during resubscription within the retention window. Replay IDs are not guaranteed to be unique.

Gain a deep understanding of Salesforce integration, from creating and configuring Connected Apps to mastering advanced topics like OAuth flows, SAML-based Single Sign-On, and Streaming APIs. Our PDF course combines practical examples, real-time scenarios, and integration patterns to equip professionals with the skills needed to streamline processes and enhance productivity. Tailored for those with 2–8 years of experience, it’s your guide to unlocking seamless connectivity between Salesforce and other systems.

Link to course : Mastering Salesforce Integration

Salesforce Integration Interview Questions and Answers Part-3

 1) What are the key steps involved in any OAuth authorization flow?

OAuth flows typically involve three main steps:

1. Access Request: The client app requests access to a protected resource.
2. Token Issuance: The authorization server grants an access token to the client app.
3. Token Validation: The resource server validates the access token and allows access to the protected resource.

2) How does the OAuth 2.0 Client Credentials Flow differ from the Username-Password Flow?

OAuth 2.0 Client Credentials Flow:

• Used for server-to-server integrations without user interaction.
• The client app exchanges its consumer key and consumer secret for an access token.
• More secure and avoids transmitting user credentials.

OAuth 2.0 Username-Password Flow:

• Authorizes a client app using stored user credentials.
• Not recommended due to security risks, as it transmits user credentials back and forth.
• Suitable only in special cases with a high degree of trust.

3) What makes the OAuth 2.0 JWT Bearer Flow secure, and when should it be used?

Security Features:

• Uses a JSON Web Token (JWT) signed with a certificate, ensuring data integrity and authenticity.
• Eliminates the need to transmit sensitive user credentials or rely on interactive logins.
• Requires prior approval of the connected app, adding an additional layer of control.

Use Case:

• Ideal for server-to-server integrations where ongoing access to Salesforce resources is needed without user interaction.

4) Why is the Username-Password Flow not recommended, and what are its key steps?

The Username-Password Flow is not recommended because it involves passing sensitive user credentials (username and password) back and forth, which can lead to security vulnerabilities, especially if the credentials are intercepted.

Key Steps:

1. The connected app sends a POST request to the Salesforce token endpoint with the user's credentials and app details (client ID, client secret, username, and password).
2. Salesforce verifies the request and grants an access token to the connected app.
3. The connected app uses the access token to access protected resources in Salesforce.

Example Usage:

A request to generate an access token includes:

grant_type=password&

client_id=<Connected_App_Consumer_Key>&

client_secret=<Connected_App_Consumer_Secret>&

username=<User_Username>&

password=<User_Password>

When to Use:

• Suitable only for scenarios with a high level of trust between the client and resource owner.
• Should only be used as a last resort, with minimal permissions and strong security measures.

5) How can you integrate two Salesforce orgs using the Username-Password Flow, and what are the main steps involved?

The integration of two Salesforce orgs using the Username-Password Flow involves securely fetching data from one org (ORG B) and displaying it in another org (ORG A). This method leverages OAuth 2.0 for authentication and the Salesforce REST API for data retrieval.

Key Steps in Integration:

In ORG B:

• Create a Connected App to allow authentication.
• Implement a RESTful Web Service to fetch data.
  
  

In ORG A:

• Configure a Remote Site Setting to allow outbound calls to ORG B.
• Create an Apex Controller to:

          a) Authenticate with ORG B using the Username-Password Flow.

The Apex controller sends a POST request to ORG B's token endpoint using the credentials and client information from the connected app.

          b) Call the web service in ORG B to fetch the required data.

Once authenticated, the controller sends an HTTP GET request to the web service in ORG B, providing query parameters.

Develop a Visualforce Page or LWC to display the retrieved information. 

6) How would you integrate two Salesforce orgs (ORG A and ORG B) using the Client Credentials Flow?

To integrate two Salesforce orgs using the Client Credentials Flow, follow these high-level steps:

Setup in ORG B:

• Create a Connected App in ORG B, enabling the Client Credentials Flow to allow secure server-to-server communication.
• Note the Consumer Key and Consumer Secret, which will be used by ORG A to authenticate.
• Implement a web service in ORG B to handle incoming requests for data creation or updates.

Setup in ORG A:

• Configure Custom Metadata or a secure storage mechanism to store the Consumer Key, Consumer Secret, and ORG B’s endpoint.
• Create Remote Site Settings in ORG A for ORG B’s API endpoint to allow external callouts.
• Develop an Apex class in ORG A to:

               a) Authenticate with ORG B using the Client Credentials Flow and retrieve an access token.

              b) Once Authenticated, Perform API callouts to ORG B’s web service to send or retrieve data as required.

Trigger Integration:

• Implement triggers or scheduled processes in ORG A to identify when data should be synchronized with ORG B based on business rules.
• Ensure error handling and logging mechanisms are in place for monitoring and troubleshooting.

This approach enables secure and efficient integration between the two Salesforce orgs, leveraging the Client Credentials Flow for authentication.

 7) What is the OAuth 2.0 JWT Bearer flow, and how does it enable server-to-server integration?

The OAuth 2.0 JWT Bearer flow is a method for enabling secure, server-to-server integration without requiring user interaction for each request. It allows a client (server) to authenticate with another server (e.g., Salesforce) by sending a digitally signed JSON Web Token (JWT) to obtain an access token.

How It Works:

1. Create a JWT: The client generates a JWT signed with its private key. This JWT includes claims like iss (issuer/client ID), sub (subject/user), aud (audience), and exp (expiration time).
2. Request Access Token: The client sends the signed JWT to the OAuth token endpoint, specifying the grant type as urn:ietf:params:oauth:grant-type:jwt-bearer.
3. Salesforce Grants Access Token: Salesforce verifies the JWT signature using the public key from the connected app's certificate. Upon successful verification, it issues an access token.
4. Access Protected Data: The client uses the access token in API requests to securely access Salesforce resources.

This flow is especially useful for system-to-system communication where user intervention is impractical or unnecessary.

8) What is the difference between a self-signed certificate and a CA-signed certificate?

The main difference lies in the issuer of the certificate:

• Self-Signed Certificate: Created, signed, and issued by the entity it is intended for. It does not involve any external validation.
• CA-Signed Certificate: Created, signed, and issued by a trusted third-party Certificate Authority (CA), which verifies the identity of the applicant.

Key Consideration: CA-signed certificates are more widely trusted but come with a cost, while self-signed certificates are free but may not be trusted by external systems.

Gain a deep understanding of Salesforce integration, from creating and configuring Connected Apps to mastering advanced topics like OAuth flows, SAML-based Single Sign-On, and Streaming APIs. Our PDF course combines practical examples, real-time scenarios, and integration patterns to equip professionals with the skills needed to streamline processes and enhance productivity. Tailored for those with 2–8 years of experience, it’s your guide to unlocking seamless connectivity between Salesforce and other systems.

Link to course : Mastering Salesforce Integration

Salesforce Integration Interview Questions and Answers Part-2

 1) What is Single sign-on (SSO)?

Single sign-on (SSO) is an authentication method that enables users to access multiple applications with one login and one set of credentials. For example, after users log in to your org, they can automatically access all apps from the App Launcher. You can set up your Salesforce org to trust a third-party identity provider to authenticate users. Or you can configure a third-party app to rely on your org for authentication.

2) What is identity provider and service provider? What are the different ways that I can implement SSO? 

When you set up SSO, you configure one system to trust another to authenticate users, eliminating the need for users to log in to each system separately. The system that authenticates users is called an identity provider. The system that trusts the identity provider for authentication is called the service provider.

Salesforce supports SSO with SAML and OpenID Connect. Salesforce also has preconfigured authentication providers that you can use to enable SSO with systems that have their own authentication protocols, like Facebook.

3) What is the role of SAML in Salesforce Single Sign-On (SSO), and how does it work between two Salesforce orgs?

SAML (Security Assertion Markup Language) enables Single Sign-On (SSO) between applications. In a Salesforce SSO scenario, one Salesforce org acts as the Identity Provider (IdP), where the user logs in, and another Salesforce org acts as the Service Provider (SP), where the user is redirected after successful authentication. The IdP authenticates the user and sends a SAML assertion to the SP to grant access.

4) How do you configure Salesforce as a SAML Identity Provider for Single Sign-On?

To configure Salesforce as a SAML Identity Provider:

Enable Identity Provider in Salesforce:

Go to Setup, search for Identity Provider, and enable it.
Select a certificate (default or custom) to establish secure communication with the Service Provider (SP). 

Share Metadata or Certificate:

Download the metadata file or certificate from the Identity Provider org and share it with the SP. This metadata contains all the necessary configurations for SSO setup in the SP org.

After configuring SSO setup in SP org, Create a Connected App in IP org:

In the Identity Provider org, create a Connected App to facilitate SAML communication:

In the Identity Provider org, create a Connected App to facilitate SAML communication:

Go to Setup > App Manager > New Connected App.

Configure fields such as:

Entity ID: The unique identifier for the Service Provider.

ACS URL: The Assertion Consumer Service URL from the SP org.

Single Logout URL: The logout endpoint from the SP org.

Subject Type: Should match the SAML Identity Type in the SP org.

Upload the IdP certificate downloaded from the Identity Provider org.

Enable Single Logout and configure logout binding to match the SP settings.

Assign Access to the Connected App:

Grant user profile access to the Connected App to allow specific users to utilize the SSO feature.

After completing these steps, users can log in through the IdP-Initiated Login URL from the Connected App in the Identity Provider org and get redirected to the Service Provider org after successful authentication.

5) How do you configure Salesforce as a SAML Service Provider for Single Sign-On?

To configure Salesforce as a SAML Service Provider:

Enable SAML in the Service Provider Org:

Go to Setup > Single Sign-On Settings and check the SAML Enabled flag.

Import Metadata from the Identity Provider (IdP):

Click New from Metadata File and upload the metadata file downloaded from the IdP org.
This auto-populates the configuration fields, such as Entity ID and ACS URL.

Configure SAML Settings:

Verify or customize key fields:

SAML Identity Type: Choose how user assertion will be validated (e.g., Federation ID).
Identity Provider Certificate: Upload the certificate from the IdP org.
Request Signing Certificate: Optionally, create a self-signed certificate in the Service Provider org to sign SAML assertions.

Enable Single Logout:

Check the Single Logout Enabled flag, and configure the Logout URL and Binding Type to match the IdP settings.

Test the Integration:

Ensure the SAML Identity Type (e.g., Federation ID) matches the user information in both orgs.
If the user does not exist, consider enabling Just-in-Time Provisioning for dynamic user creation.

By following these steps, the Service Provider org is now ready to accept SAML assertions from the Identity Provider org for seamless Single Sign-On.

6) What is Just-in-Time (JIT) Provisioning in Salesforce, and how is it used in Single Sign-On (SSO)?

Just-in-Time (JIT) Provisioning in Salesforce is a feature that automatically creates or updates user accounts in the Service Provider (SP) org during the Single Sign-On (SSO) process. It simplifies user management by eliminating the need to pre-create user accounts in the SP org.

How JIT Works:

• The Identity Provider (IdP) sends user information in a SAML 2.0 assertion during the authentication process.
• Salesforce processes this information using a JIT handler (Apex class) or standard JIT settings.
• If the user does not already exist in the SP org, a new user account is created in real-time.

Example Use Case:

In a multi-org setup, if a user logs in to an Identity Provider org but their account does not exist in the SP org, JIT creates the account dynamically based on the information provided in the SAML assertion.

7) What are SAML Request, SAML Response, and SAML Assertion in the context of Single Sign-On (SSO), and how do they function?

SAML Request:

When a user tries to access a Service Provider (SP), the SP sends a SAML Request to the Identity Provider (IdP).
This request asks the IdP to authenticate the user.

SAML Response:

After authenticating the user, the IdP sends a SAML Response back to the SP.
The response includes a signed SAML Assertion containing user details.

SAML Assertion:

• A SAML Assertion is part of the SAML Response and asserts facts about the user, such as their username or email address.
• The assertion is signed by the IdP to ensure its authenticity.
• The SP validates this signature to confirm the integrity of the information.

How They Work Together:

• The SAML Request initiates the SSO process.
• The SAML Response conveys the authentication result.
• The SAML Assertion provides the necessary user details to complete the authentication and grant access.

This process ensures secure, seamless user authentication between the Identity Provider and Service Provider.

8) What is an Identity Provider-Initiated SAML Flow, and how does it work?

Identity Provider-Initiated SAML Flow is a Single Sign-On (SSO) process where the login begins at the Identity Provider (IdP).

Steps:

• The user logs in to the identity provider.
• The user clicks a button or link to access the service provider. For example, the user clicks an app on the App Launcher page in a Salesforce org.
• The identity provider initiates login by sending a cryptographically signed SAML response to the service provider. The SAML response contains a SAML assertion that tells the service provider who the user is.
• The service provider validates the signature in the SAML response and identifies the user.
• The user is now logged in to the service provider.

9) How does a Service Provider-Initiated SAML Flow differ from an Identity Provider-Initiated SAML Flow?

• In service provider initiated flow the user starts from service provider trying to access a service.
• The service provider initiates login by sending a SAML request to the identity provider, asking it to authenticate the user.
• The identity provider sends the user to a login page.
• The user enters their identity provider login credentials and the identity provider authenticates the user.
• The identity provider now knows who the user is, so it sends a cryptographically signed SAML response to the service provider. The SAML response contains a SAML assertion that tells the service provider who the user is.
• The service provider validates the signature in the SAML response and identifies the user.
• The user is now logged in to the service provider and can access the protected resource.

Gain a deep understanding of Salesforce integration, from creating and configuring Connected Apps to mastering advanced topics like OAuth flows, SAML-based Single Sign-On, and Streaming APIs. Our PDF course combines practical examples, real-time scenarios, and integration patterns to equip professionals with the skills needed to streamline processes and enhance productivity. Tailored for those with 2–8 years of experience, it’s your guide to unlocking seamless connectivity between Salesforce and other systems.

Link to course : Mastering Salesforce Integration

Salesforce Integration Interview Questions and Answers Part-1

1) What are the main differences between REST and SOAP APIs in Salesforce, and when would you choose one over the other?

Differences between REST and SOAP APIs:

Format and Simplicity:

REST API: Supports both JSON and XML formats. It is lightweight, easy to use, and well-suited for modern web and mobile applications.

SOAP API: Supports only XML format, which can be more complex to handle.

Protocol and Methods:

REST API: Uses standard HTTP methods such as GET, POST, PUT, DELETE, etc.

SOAP API: Relies on a strict XML messaging protocol and includes a WSDL (Web Services Description Language) file for communication.

When to Choose:

Choose REST API when simplicity, speed, and modern formats like JSON are needed.

Choose SOAP API when integration demands more robust error handling, advanced security, or backward compatibility with older systems.

2) What is Salesforce Connect, and in what scenarios would you recommend using it for integration?

Salesforce Connect is a feature that allows users to access and display external data within Salesforce without storing it in Salesforce databases. It uses external objects to map to external data tables and accesses data on demand in real time.

Scenarios for Using Salesforce Connect:

1. Large Data Volumes: When you have large datasets that you don't want to replicate in Salesforce.

2. Real-Time Data Access: When you need real-time access to the latest external data instead of working with stale data copies.

3. Efficient Data Retrieval: When only small amounts of data are needed at a time, minimizing the need for storage and replication.

Advantages:

• Avoids data redundancy.
• Ensures up-to-date and accurate information.
• Simplifies integration with minimal data storage overhead.

Example Use Case: A company might use Salesforce Connect to access customer data stored in an external ERP system, ensuring sales teams always have the most up-to-date order and account details without duplicating that data in Salesforce.

3) What is the Bulk API in Salesforce, and when should it be used?

The Bulk API is designed for handling large-scale data operations asynchronously. It supports insert, update, delete, upsert, and query operations in batches, making it ideal for processing thousands or millions of records efficiently.

When to Use:

• When working with large data sets (e.g., over 2,000 records).
• For data migrations or regular bulk updates.
• To optimize performance and avoid API call limits.

4) What is the Streaming API, and give one example of use case?

The Streaming API enables real-time event streaming using push technology. It supports events like PushTopic, platform events, Change Data Capture, and generic events.

Use Case: A logistics company might use the Streaming API to push real-time updates about shipment status changes from Salesforce to a mobile app used by delivery drivers.

5) What is a Connected App in Salesforce, and why is it important for integration?

A connected app in Salesforce is designed to enable external applications to integrate with Salesforce APIs securely. For example:

• To use OAuth authorization for external apps, configure the connected app with appropriate OAuth settings.
• For SAML single sign-on (SSO) flows, configure SAML settings.

6) How to determine if your org is an owner or consumer of a Connected App?

As a connected app owner, your Salesforce organization built the app. You can edit the app’s characteristics and manage its access policies.

As a connected app consumer, your organization installed the app from the AppExchange Marketplace or as a managed package from a third-party vendor’s website. You can only edit the app’s access policies

7) What permissions are required to create, update, or delete a connected app in Salesforce?

To manage connected apps, a user needs the Customize Application permission, along with either:

• Modify All Data or
• Manage Connected Apps permissions.

8) What is callback URL?

A callback URL is the URL that is invoked after OAuth authorization for the consumer (connected app). In some contexts, the URL must be a real URL that the client’s web browser is redirected to. In others, the URL isn’t actually used, but the value between your client app and the server (the connected app definition) must be the same.

9) What does the "Token Valid for" setting in a Salesforce connected app define, and what are the configurable options for its duration?

The "Token Valid for" setting defines the duration for which an OAuth token(such as the access token) remains valid in Salesforce. The duration can be configured between 1 minute and 720 minutes (12 hours), with the default being 120 minutes (2 hours). Shorter durations enhance security by limiting token misuse, while longer durations provide convenience in trusted systems.

Gain a deep understanding of Salesforce integration, from creating and configuring Connected Apps to mastering advanced topics like OAuth flows, SAML-based Single Sign-On, and Streaming APIs. Our PDF course combines practical examples, real-time scenarios, and integration patterns to equip professionals with the skills needed to streamline processes and enhance productivity. Tailored for those with 2–8 years of experience, it’s your guide to unlocking seamless connectivity between Salesforce and other systems.

Link to course : Mastering Salesforce Integration

Streamlining Salesforce Admin Tasks: Accessing Object Permissions with the Winter '25 Update

The Winter '25 release introduces an exciting new feature for Salesforce admins: the ability to quickly view object permissions directly in Object Manager. This update is designed to simplify your workflow, making it easier to troubleshoot access issues and ensure security compliance.

Introducing the Object Access Feature in Object Manager - Winter '25 Update

In the Object Manager, a new Object Access menu item is now available in the sidebar. This feature offers a read-only summary of the permission sets, permission set groups, and profiles that grant access to any object. It gives you a clear, consolidated view of all relevant permissions, such as who can read, create, edit, or delete records.

Benefits for Admins:

1. Troubleshoot Access Issues Faster

You no longer need to switch between profiles or permission sets to diagnose access problems. The Object Access Summary presents all the information you need in one place, saving you time and simplifying the troubleshooting process.

2. Simplify Security Reviews

If you're conducting a security review or preparing for a compliance audit, having a complete view of object permissions helps ensure your data is secure and that the correct individuals have the right level of access.

3. Make Informed Decisions

With a clear understanding of how object access is granted, you can confidently make adjustments to permissions, ensuring you maintain security while giving users the access they need to perform their roles effectively.

To use the Object Access feature, follow these steps:

1. Go to Setup.

2. Open Object Manager.

3. Select the object you want to view.

4. In the sidebar, click on Object Access.